converting from perl: variable sized unpack

Quinn Dunkan quinn at
Fri Jul 20 21:49:19 EDT 2001

On Thu, 19 Jul 2001 12:36:49 +0100, phil hunt <philh at>
>On 18 Jul 2001 21:19:54 GMT, Quinn Dunkan <quinn at> wrote:
>>It's not just you, but I don't agree, and it's not just me either.
>>NameErrors, KeyErrors, and IndexErrors have saved me many times.  One of the
>>things I didn't like about perl is how it magically created values on
>>reference, and then I had to go hunt down the bad reference that created it.
>>And I often store None in dicts and lists.  It would be weird if d.has_key(x)
>>could be true or false while d[x] always evaluated to None.  That means that
>>d[x] is implicitly creating a None when d.has_key(x) is false,
>It doesn't, it's just returning a value.

But where is that value coming from?  It wasn't stored in the dict!

Too me, the following:

>>> d = {}
>>> d.has_key('foo')
0           # foo doesn't exist
>>> d['foo']
>>> d['foo'] = None
>>> d.has_key('foo')
1           # foo exists
>>> d['foo']

seems inconsistent with:

>          X = None should be different than X not existing.

And keep in mind that looking up global names and looking up object attributes
are conceptually dictionary lookups (in globals() and obj.__dict__,

>                                         Though I can see how that
>might be useful, e.g:
>Note this involves:
>(1) if you refer to a variable that doesn't exist, it creatres it giving
>it the value None
>(2) None.__getitem__() makes it into a Dictionary
>(3) Dict:__getitem__() on an item not found returns None
>(4) None + a number equals that number

This is the kind of automatic creation and coercion that many people love
about perl.  Many other people, however, don't :)

More information about the Python-list mailing list