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

[Peter Hansen]

Weiguang Shi wrote:

In article <lI************ ********@rogers .com>, Dan Perl wrote:

That would not be justified in python. The type of b[1] is
undetermine d until initialization and I don't see why it should be
an int by default.

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.

Why would it tell Python that?

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

{1: 3.5}

So at this point, it can clearly be either an integer or
a float. Doubtless it could also be an object which
overloads the += operator with integer arguments, though
what it might actually do is anyone's guess.

-Peter

[Berthold Höllmann]

wg***@namao.cs. ualberta.ca (Weiguang Shi) writes:

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.

It isn't :-)

a={}
a[1] = a.get(1, 0) + 1
a {1: 1} a[1] = a.get(1, 0) + 1
a

{1: 2}

Regards
Berthold
--
be******@xn--hllmanns-n4a.de / <http://höllmanns.de/>
bh***@web.de / <http://starship.python .net/crew/bhoel/>

[Josiah Carlson]

wg***@namao.cs. ualberta.ca (Weiguang Shi) wrote:

In article <lI************ ********@rogers .com>, Dan Perl wrote:

I don't know awk, so I don't know how your awk statement works.

It doesn't hurt to give it a try :-)

Even when it comes to the python statements, I'm not sure exactly what the
...

I see your point.

You're saying that in awk a['hello'] is initialized to 0.

More than that; I said awk recognizes a['hello']++ as an
arithmetic operation and initializes a['hello'] to 0 and add one to
it. (This is all guess. I didn't implement gawk. But you see my point.)

That would not be justified in python. The type of b[1] is
undetermined until initialization and I don't see why it should be
an int by default.

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. Based on these, shouldn't Python be able to insert the pair
"1:0" into a{} before doing the increment?

As Peter has already mentioned, since b[1] doesn't exist until you
assign it, the type of b[1] is ambiguous.

The reason Python doesn't do automatic assignments on unknown access is
due to a few Python 'Zens'

import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Specifically:
Explicit is better than implicit.
(you should assign what you want, not expect Python to know what you
want)
Special cases aren't special enough to break the rules.
(incrementing non-existant values in a dictionary shouldn't be any
different from accessing non-existant values)
In the face of ambiguity, refuse the temptation to guess.
(what class/value should the non-existant value initialize to?)
Learn the zens. Any time you have a design question about the Python,
check the zens, then check google, then check here.

- Josiah

[Weiguang Shi]

I see.

Thanks
Weiguang

[Jeffrey Froman]

Weiguang Shi wrote:

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 ... <snip>
I have to initialize b[1] explicitly in the first place.

You could use the dictionary's setdefault method, if your value is mutable:

b={}
for n in xrange(100): .... b.setdefault('f oo', [0])[0] += 1
.... b['foo'][0]

100

Jeffrey

[Gerrit]

Peter Hansen wrote:

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.

Why would it tell Python that?

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]

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:

...

>>> a = {}
>>> a['1'] = 5
>>> a['1'] *= 2
>>> a['1'] 10
>>> a['1'] = "blah"
>>> a['1'] *= 2
>>> a['1'] 'blahblah'
>>> a['1'] = ['a', 8]
>>> a['1'] *= 2
>>> a['1']

['a', 8, 'a', 8]

The type of the right hand operator does not have nothing to do with
the
type of the left operand!

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]

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
<wg***@namao.cs .ualberta.ca> wrote:

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

[Weiguang Shi]

Caleb,

In article <op************ **@news.telkoms a.net>, Caleb Hattingh wrote:

...
And then have x=1? Is this the question of debate here? One line of
initialisati on to specify the type? Right.

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.

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]

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

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.
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
Keep well
Caleb