dictionary initialization

[Jeff Shannon]

Personally, I think

a++

in awk is much more elegant than

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

As others have pointed out, the type of an uninitialized a 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

 

[Caleb Hattingh]

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

 

[Alex Martelli]

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]

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

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]

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