dictionary initialization

[Gerrit]

Re: dictionary initialization

Peter Hansen wrote:[color=blue][color=green]
> >In my example, it was b[1]+=1. "+=1" should at least tell Python two
> >things: this is an add operation and one of the operands is an
> >integer.[/color]
>
> Why would it tell Python that?[/color]

Well, the rhs of 'foo+=1' is always an integer.

Gerrit.

--
Weather in Lulea / Kallax, Sweden 26/11 17:20:
-8.0°C wind 6.7 m/s NW (34 m above NAP)
--
In the councils of government, we must guard against the acquisition of
unwarranted influence, whether sought or unsought, by the
military-industrial complex. The potential for the disastrous rise of
misplaced power exists and will persist.
-Dwight David Eisenhower, January 17, 1961

[Weiguang Shi]

Re: dictionary initialization

Just received an email from Batista, Facundo. Below are some quote and
my reply.

On Fri, Nov 26, 2004 at 09:09:46AM -0300, Batista, Facundo wrote:[color=blue]
> ...[color=green][color=darkred]
> >>> a = {}
> >>> a['1'] = 5
> >>> a['1'] *= 2
> >>> a['1'][/color][/color]
> 10
>[color=green][color=darkred]
> >>> a['1'] = "blah"
> >>> a['1'] *= 2
> >>> a['1'][/color][/color]
> 'blahblah'
>[color=green][color=darkred]
> >>> a['1'] = ['a', 8]
> >>> a['1'] *= 2
> >>> a['1'][/color][/color]
> ['a', 8, 'a', 8]
>
> The type of the right hand operator does not have nothing to do with
> the
> type of the left operand!
>[/color]

You mean in Python, of course. I can see this is going the religious
direction now.

All in all, I've realized when a language generalizes and abstracts,
it loses convenience. Because of this, however powerful other
languages become, awk always has its place as long as the application
is there.

Weiguang

[Caleb Hattingh]

Re: dictionary initialization

Hi Weiguang

I know how it is when discussion becomes religious, and I want to avoid
that. First, I want to clarify exactly what it is that you are saying:

Would I be correct in saying that your point is that with awk, you can
just do something like (ignore the syntax)

(x not existing yet)
x+=1

And have x = 1, while in Python you have to do

(x not existing yet)
x=0
x+=1

And then have x=1? Is this the question of debate here? One line of
initialisation to specify the type?

IF this is the point you are making, and the awk functionality demostrated
in this particular example is a really significant feature for you in your
specific problem domain, then I must concede that awk is probably right
for you, and you shouldn't waste your time with Python.

Keep well
Caleb


On Fri, 26 Nov 2004 17:53:12 +0000 (UTC), Weiguang Shi
<wgshi@namao.cs .ualberta.ca> wrote:
[color=blue]
>
> You mean in Python, of course. I can see this is going the religious
> direction now.
>
> All in all, I've realized when a language generalizes and abstracts,
> it loses convenience. Because of this, however powerful other
> languages become, awk always has its place as long as the application
> is there.
>
> Weiguang[/color]

[Weiguang Shi]

Re: dictionary initialization

Caleb,

In article <opsh3pirx21js0 xs@news.telkoms a.net>, Caleb Hattingh wrote:[color=blue]
> ...
>And then have x=1? Is this the question of debate here? One line of
>initialisati on to specify the type?[/color]
Right.
[color=blue]
>
>IF this is the point you are making, and the awk functionality
>demostrated in this particular example is a really significant
>feature for you in your specific problem domain, then I must concede
>that awk is probably right for you, and you shouldn't waste your
>time with Python.[/color]
Thanks for the advice. I'll stay with awk and shell for most of my
text processing (simple but, hey, 90% of the time I'm not doing
anything complex) and go Python for binary data processing and larger
projects. BTW, I think learning Python is a good use of my time.

Weiguang

[Dan Perl]

Re: dictionary initialization


"Caleb Hattingh" <caleb1@telkoms a.net> wrote in message
news:opsh3pirx2 1js0xs@news.tel komsa.net...[color=blue]
> Hi Weiguang
>
> I know how it is when discussion becomes religious, and I want to avoid
> that. First, I want to clarify exactly what it is that you are saying:
>
> Would I be correct in saying that your point is that with awk, you can
> just do something like (ignore the syntax)
>
> (x not existing yet)
> x+=1
>
> And have x = 1, while in Python you have to do
>
> (x not existing yet)
> x=0
> x+=1
>
> And then have x=1? Is this the question of debate here? One line of
> initialisation to specify the type?
>
> IF this is the point you are making, and the awk functionality demostrated
> in this particular example is a really significant feature for you in your
> specific problem domain, then I must concede that awk is probably right
> for you, and you shouldn't waste your time with Python.[/color]

And just like that, the discussion turned religious. It's hard to assess
someone's tone when it comes in writing, but, Caleb, you sound sarcastic and
belligerent to me.

Yes, 2 lines instead of 1 is an issue. And it is not the only example where
the "explicit is better than implicit" principle shows a downside. However,
addressing Weiguang's statements, I wouldn't say that python is less
convenient than other languages (particularly awk, although I don't know
that language), because I am sure we can find examples where python can
implement something in a simpler way.

Dan
[color=blue]
> Keep well
> Caleb[/color]

[Terry Reedy]

Re: dictionary initialization


"Dan Perl" <danperl@rogers .com> wrote in message
news:ufmdneh24K VgEjrcRVn-pw@rogers.com.. .[color=blue]
>
> "Caleb Hattingh" <caleb1@telkoms a.net> wrote in message
> news:opsh3pirx2 1js0xs@news.tel komsa.net...[color=green]
>> IF this is the point you are making, and the awk functionality
>> demostrated in this particular example is a really significant feature
>> for you in your specific problem domain, then I must concede that awk is
>> probably right for you, and you shouldn't waste your time with Python.[/color]
>
> And just like that, the discussion turned religious. It's hard to assess
> someone's tone when it comes in writing, but, Caleb, you sound sarcastic
> and belligerent to me.[/color]

To me, Caleb was being only slightly and possibly sarcastic in the process
of giving friendly good advice to the effect of "better to use Awk and
produce than to beat you head against a wall trying to change a basic
Python design decision.

Almost every design decision has plusses and minuses for designers and
others to weigh. No matter what the designer decides, there will be users
who weigh the factors enough differently to really wish that the decision
was otherwise. In fact, there will probably be another language whose
designer did decide otherwise. And in this case, with regard to the
handling of uninitialized variables, there is.

A Python religion fanatic might have made the opposite suggestion --
something like 'your factor weighting is wrong; see the light and bow to
the superior wisdom of how Python does it'.

Terry J. Reedy

[Jeff Shannon]

Re: dictionary initialization

Weiguang Shi wrote:
[color=blue]
>Personally, I think
>
> a[i]++
>
>in awk is much more elegant than
>
> if i in a: a[i] += 1
> else: a[i] = 1
>
>[/color]

As others have pointed out, the type of an uninitialized a[i] is
ambiguous, and that Python doesn't want to try to guess what type to use
based only on the type of the RHS. Depending on what, exactly, the RHS
*is*, there may be multiple likely types for the LHS. The case where
the RHS is an integer is one of the clearer special cases, but Python's
default behavior should be the same regardless of what type the RHS is,
and it doesn't seem safe to assume that the LHS type should always be
equivalent to the RHS type.

But there's another level of ambiguity here. In many cases, throwing an
error for an uninitialized dict item *is* the correct behavior. Suppose
I've got an ascii string representing a DNA gene sequence, and I want to
calculate the relative prevalence of various bases. It's pretty
straightforward to go through and count up how many of each character
there are, using a dict -- but if somehow a letter other than A, G, C,
or T is present, I don't want it to pass silently. It's something very
strange/wrong, and I want to be notified immediately.

Now, in the counting that *you* happen to be doing, assuming that a
default value is desirable works. But that's not universal. And it's
easier to use one of various methods to create a default value (as Bengt
Richter demonstrated) than it is to consistently check that the dict
keys are limited to a particular set of desired keys.

Also, it's not that hard to subclass dict to provide the functionality
that you want. I expect that googling on the c.l.p archives would turn
up more than one recipe for a dict with default values. (There may even
be such a thing in the Python Cookbook.) I know I've seen such things
posted here (though not recently).

Jeff Shannon
Technician/Programmer
Credit International

[Alex Martelli]

Re: dictionary initialization

Jeff Shannon <jeff@ccvcorp.c om> wrote:
[color=blue]
> Also, it's not that hard to subclass dict to provide the functionality
> that you want. I expect that googling on the c.l.p archives would turn
> up more than one recipe for a dict with default values. (There may even
> be such a thing in the Python Cookbook.) I know I've seen such things
> posted here (though not recently)[/color]

There are several such recipes. The most promising IMHO is Hettinger's
'bag' class (doesn't subclass dict -- uses containment and delegation --
but it deals best with maintaining count-per-item, aka multiset or bag);
it has several bugs as posted, but I've just finished editing it for the
2n edition and it wasn't hard to clear up. I do hope we'll have a
collections.bag in Python 2.5 one day.


Alex

[Peter Hansen]

Re: dictionary initialization

Caleb Hattingh wrote:[color=blue]
> IF this is the point you are making, and the awk functionality
> demostrated in this particular example is a really significant feature
> for you in your specific problem domain, then I must concede that awk
> is probably right for you, and you shouldn't waste your time with Python.[/color]

Unfortunately for the logic, if one finds something like
that to be a "really significant feature ... [in a] specific problem
domain", then with Python you can of course create your own
custom data type which behaves exactly as desired. And in fact
it is likely that there is additional behaviour that could be
added that would make the Python approach to the problem *even
simpler than the awk approach*, but maybe that's getting too
much of a good thing...

Of course, this capability prevents one from whining about how
wonderful a specialized limited-purpose tool is compared to
that waste of space called Python, but if it weren't for people
like that Usenet would have no traffic and we'd all have lives
instead.

-Peter

[Caleb Hattingh]

Re: dictionary initialization

Peter,

Right :)

I was trying to kill off (with kindness) a thread that just wasn't making
sense. The other respondents gave pretty good technical explanations
regarding the dynamic typing rules, but I suspect the OP's assertion was
just what I described in the simplest terms I could. Which doesn't make
sense as a critical language feature/flaw.

thx
Caleb

On Sat, 27 Nov 2004 12:59:00 -0500, Peter Hansen <peter@engcorp. com> wrote:
[color=blue]
> Caleb Hattingh wrote:[color=green]
>> IF this is the point you are making, and the awk functionality
>> demostrated in this particular example is a really significant feature
>> for you in your specific problem domain, then I must concede that awk
>> is probably right for you, and you shouldn't waste your time with
>> Python.[/color]
>
> Unfortunately for the logic, if one finds something like
> that to be a "really significant feature ... [in a] specific problem
> domain", then with Python you can of course create your own
> custom data type which behaves exactly as desired. And in fact
> it is likely that there is additional behaviour that could be
> added that would make the Python approach to the problem *even
> simpler than the awk approach*, but maybe that's getting too
> much of a good thing...
>
> Of course, this capability prevents one from whining about how
> wonderful a specialized limited-purpose tool is compared to
> that waste of space called Python, but if it weren't for people
> like that Usenet would have no traffic and we'd all have lives
> instead.
>
> -Peter[/color]

[caleb.hattingh@gmail.com]

Re: dictionary initialization

Hi Dan

I must confess that upon rereading my words, there is some irony there
(but not really sarcasm, is there?). However, I *really* tried to keep
my tone, well, professional. I realise I didn't do a good job and
apologise. I hope that's ok.

Keep well
Caleb

[Dan Perl]

Re: dictionary initialization

<caleb.hattingh @gmail.com> wrote in message
news:1102595826 .081703.57660@f 14g2000cwb.goog legroups.com...[color=blue]
> Hi Dan
>
> I must confess that upon rereading my words, there is some irony there
> (but not really sarcasm, is there?). However, I *really* tried to keep
> my tone, well, professional. I realise I didn't do a good job and
> apologise. I hope that's ok.
>
> Keep well
> Caleb
>[/color]

It's water under the bridge. I admire though the fact that you sent this
message.

Dan