Benjamin Peterson schrieb:
> In several places in the C code, there are instances where all
> exceptions can be completely ignored (akin to a bare except
> statement.) after a PyObject_GetAttr call.
>
> A week ago, I fixed one of these in hasattr (issue 2196) by
> propagating exceptions that don't inherit Exception (SystemExit,
> KeyboardInterrupt). However, there is another patch that propagates
> anything that is not a AttributeError (issue 1574217).
>
> How should we approach this?
Oh, you are bringing something to my mind. In Python 2.x hasattr()
swallows every exception. This is a major issue for applications like
ZODB, because database conflict errors must be propagated to the
conflict resolution machinery.
Shane Hathaway said once:
---
That said, I was surprised to discover that Python 2.3 implements
hasattr this way (from bltinmodule.c):
v = PyObject_GetAttr(v, name);
if (v == NULL) {
PyErr_Clear();
Py_INCREF(Py_False);
return Py_False;
}
Py_DECREF(v);
Py_INCREF(Py_True);
return Py_True;
It should not swallow all errors, especially now that descriptors make
computed attributes quite common. getattr() only recently started
catching only AttributeErrors, but apparently hasattr is lagging behind.
I suggest the consistency between getattr and hasattr should be fixed
in Python, not Zope.
---
Thankfully this issue was fixed in Python 2.6 and 3.0. In newer versions
of Python hasattr() only swallows exception based on the Exception class
but not BaseExceptions. We should make sure all code in the core behaves
the same way. Exceptions based on BaseException must *never* be
swallowed. The behavior may even be worse a macro and it should be
documented in large, friendly and red letters in the C API docs. *wink*
Christian
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
