[Python-Dev] Re: Another test_compiler mystery

[Tim Peters]

[Tim Peters]
>> AAAARGHGH!  lookdict "isn't allowed" to raise
>> exceptions, so it does a PyErr_Clear(), goes on to futilely chase the
>> entire dict looking for another match on the hash code, and we've
>> effectively turned a MemoryError into a KeyError.

[Greg Ewing]
> This suggests to me that the very concept of a function
> that's not allowed to return errors is dubious, since
> even just calling another function could provoke a
> MemoryError.

I believe I had a more elegant way to say that:  AAAARGHGH! <wink>

Alas, 10 billion call sites, including in external extensions, rely on
that a NULL return from PyDict_GetItem() or PyDict_GetItemString() is
the unexceptional "nope, the key's not there".  So there's no
realistic chance of repairing this before Python 3.0 (if even then). 
In the meantime, KeyError is confusable with almost all exceptions.

For some real fun, ask on a Zope list about hasattr() suppressing all
exceptions.  Not that Guido ever expected a hasttr() call to try to
mess with persistent objects across a networked database as side
effect.

Python originally had only string-keyed dicts, and the basic dict API
still reflects that a dict lookup simply "can't fail" for any reason
other than "key ain't there".  That used to be true.  For that matter,
hasattr() was originally no worse than a string-keyed dict lookup too,
so "can't fail" also made good sense there at the time.