[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4