dictionary initialization

[Weiguang Shi]

Hi,

With awk, I can do something like
$ echo 'hello' |awk '{a[$1]++}END{for(i in a)print i, a[i]}'

That is, a['hello'] was not there but allocated and initialized to
zero upon reference.

With Python, I got

b={}
b[1] = b[1] +1

Traceback (most recent call last):
File "<stdin>", line 1, in ?
KeyError: 1

That is, I have to initialize b[1] explicitly in the first place.

Personally, I think

a[i]++

in awk is much more elegant than

if i in a: a[i] += 1
else: a[i] = 1

I wonder how the latter is justified in Python.

Thanks,
Weiguang

[Terry Reedy]

"Dan Perl" <da*****@rogers .com> wrote in message
news:uf******** ************@ro gers.com...

"Caleb Hattingh" <ca****@telkoms a.net> wrote in message
news:op******** ******@news.tel komsa.net...

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.

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.

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]

Weiguang Shi wrote:

Personally, I think

a[i]++

in awk is much more elegant than

if i in a: a[i] += 1
else: a[i] = 1

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]

Jeff Shannon <je**@ccvcorp.c om> wrote:

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)

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]

Caleb Hattingh wrote:

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.

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]

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 <pe***@engcorp. com> wrote:

Caleb Hattingh wrote:

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.

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]

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]

<ca************ @gmail.com> wrote in message
news:11******** *************@f 14g2000cwb.goog legroups.com...

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

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

Dan