Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
diff --git a/Misc/NEWS b/Misc/NEWS
index a58f363..667c89e 100644
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -12,6 +12,14 @@
Core and builtins
-----------------
+- Some horridly obscure problems were fixed involving interaction
+ between garbage collection and old-style classes with "ambitious"
+ getattr hooks. If an old-style instance didn't have a __del__ method,
+ but did have a __getattr__ hook, and the instance became reachable
+ only from an unreachable cycle, and the hook resurrected or deleted
+ unreachable objects when asked to resolve "__del__", anything up to
+ a segfault could happen. That's been repaired.
+
- dict.pop now takes an optional argument specifying a default
value to return if the key is not in the dict. If a default is not
given and the key is not found, a KeyError will still be raised.
@@ -77,7 +85,7 @@
return 'not a == b' rather than 'a != b'. This gives the desired
result for classes that define __eq__ without defining __ne__.
-- sgmllib now supports SGML marked sections, in particular the
+- sgmllib now supports SGML marked sections, in particular the
MS Office extensions.
- The urllib module now offers support for the iterator protocol.
@@ -154,10 +162,10 @@
- EasyDialogs dialogs are now movable-modal, and if the application is
currently in the background they will ask to be moved to the foreground
before displaying.
-
+
- OSA Scripting support has improved a lot, and gensuitemodule.py can now
be used by mere mortals.
-
+
- The IDE (in a framework build) now includes introductory documentation
in Apple Help Viewer format.