[Python-Dev] Re: Another test_compiler mystery (original) (raw)

Tim Peters tim.peters at gmail.com
Wed Aug 11 04:26:31 CEST 2004

[Tim Peters]

AAAARGHGH! lookdict "isn't allowed" to raise exceptions, so it does a PyErrClear(), 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!

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.

More information about the Python-Dev mailing list