classification
Title: dict key comparison swallows exceptions
Type: Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: arigo, tim_one (2)
Priority: normal Keywords

Created on 2005-08-29 10:30 by arigo, last changed 2006-06-01 15:56 by tim_one.

Files
File name Uploaded Description Edit Remove
test59.py arigo, 2005-08-29 10:30 KeyError instead of RuntimeError
Messages (3)
msg26139 - (view) Author: Armin Rigo (arigo) Date: 2005-08-29 10:30
This is an old one that has just biten again and cost a
lot of debugging time again: the dict lookup function
swallows all errors during key comparison.  This is bad
in itself, but if the current stack depth is just wrong
then *any* comparison will raise a RuntimeError and
lookup will pretend that the dictionary is essentially
empty.  The attached sample program shows this and
crashes with a KeyError instead of a RuntimeError.

While at the C level there is a basic compatibility
problem involved (PyDict_GetItem() not allowed to raise
any exception -- see
http://thread.gmane.org/gmane.comp.python.devel/62427),
I think it should be possible to improve the situation
on the Python interface.  Unless someone points me to
something I missed, I plan to come up with a patch that
changes the internal dict functions (including
lookdict()) to let exceptions pass through, and have
the exceptions swallowed only by the PyDict_*() API
functions that require it.

The possible (remote) incompatibility here is existing
code relying on the exceptions being swallowed --
either Python code, or C code using PyObject_GetItem()
or PyMapping_GetItemString().  Such code deserves to be
shot down in my opinion.

Assigned to mwh for his feedback (not because I want
him to write the patch!).
msg26140 - (view) Author: Armin Rigo (arigo) Date: 2006-05-29 16:55
Logged In: YES 
user_id=4771

Proposed patch #1497053.
msg26141 - (view) Author: Tim Peters (tim_one) Date: 2006-06-01 15:56
Logged In: YES 
user_id=31435

Patch 1497053 was checked in as revision 46589 of the trunk
for Python 2.5, so closing this.  Because it changes
semantics, it should not be backported to 2.4.
History
Date User Action Args
2005-08-29 10:30:26arigocreate