converting from perl: variable sized unpack

[Quinn Dunkan]

On Thu, 19 Jul 2001 12:36:49 +0100, phil hunt <philh at comuno.freeserve.co.uk>
wrote:
>On 18 Jul 2001 21:19:54 GMT, Quinn Dunkan <quinn at yak.ugcs.caltech.edu> 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']
None
>>> d['foo'] = None
>>> d.has_key('foo')
1           # foo exists
>>> d['foo']
None

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__,
respectively).


>                                         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 :)