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