Shane Hathaway wrote:
On Friday 09 July 2004 11:50 am, Casey Duncan wrote:
On Fri, 9 Jul 2004 16:22:17 +0200 Dieter Maurer <dieter@handshake.de> wrote: [..]
The "hasattr" replacement in Python's "__builtin__" could look like:
_marker = [] def hasattr(obj, attr): return getattr(obj, attr, _marker) is not _marker
Hmm. I just heard about this "hasattr geddon". hasattr is *good*. Why are we fixing hasattr and bare excepts when the real problem is ZODB? ZODB should *not* be sensitive to the way the application handles ConflictErrors. When a ConflictError (or ReadConflictError) occurs, the transaction should fall into an "uncommitable" state. From this state, you can only abort the transaction; any attempts to write an object or commit cause another ConflictError. Then, only code that can guarantee that the attempted transaction is complete should actually abort the transaction, and fortunately ZPublisher fits that role. Today, the abort is implicit, and that's the mistake that has caused us to litter the code with knowledge of ConflictErrors. With the "uncommitable" state, it would not matter if the application swallows ConflictErrors.
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.
Guido rejected that idea 18 months ago. I think he is wrong, and after som discussion on #python-dev today (which practically enough was a python bug day) there seemed to be some support for this there too. It might be worth raising this on the python-dev mailing list. The main reason for not doing this change seems to be that it would break too much code. Here we have a case where lot's of code IS broken and will be fixed. ;) If this doesn't happen in Python 2.4, I think Zope patching this is the best solution. It is natural to use hasattr, and it will be very hard to get the whole zope-community to stop using it. https://sourceforge.net/tracker/index.php?func=detail&aid=504714&group_id=54...