mirror of
https://github.com/python/cpython.git
synced 2025-10-17 04:08:28 +00:00
f6b8045ca5
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). |
||
|---|---|---|
| .. | ||
| RPM | ||
| ACKS | ||
| AIX-NOTES | ||
| BeOS-NOTES | ||
| BeOS-setup.py | ||
| cheatsheet | ||
| find_recursionlimit.py | ||
| gdbinit | ||
| HISTORY | ||
| indent.pro | ||
| NEWS | ||
| NEWS.help | ||
| Porting | ||
| PURIFY.README | ||
| pymemcompat.h | ||
| python-mode.el | ||
| python.man | ||
| README | ||
| RFD | ||
| setuid-prog.c | ||
| SpecialBuilds.txt | ||
| vgrindefs | ||
Python Misc subdirectory ======================== This directory contains files that wouldn't fit in elsewhere. Some documents are only of historic importance. Files found here ---------------- ACKS Acknowledgements AIX-NOTES Notes for building Python on AIX BeOS-NOTES Notes for building on BeOS BeOS-setup.py setup.py replacement for BeOS, see BeOS-NOTES cheatsheet Quick summary of Python by Ken Manheimer find_recursionlimit.py Script to find a value for sys.maxrecursionlimit gdbinit Handy stuff to put in your .gdbinit file, if you use gdb HISTORY News from previous releases -- oldest last HPUX-NOTES Notes about dynamic loading under HP-UX indent.pro GNU indent profile approximating my C style NEWS News for this release (for some meaning of "this") Porting Mini-FAQ on porting to new platforms PURIFY.README Information for Purify users python.man UNIX man page for the python interpreter python-mode.el Emacs mode for editing Python programs README The file you're reading now RFD Request For Discussion about a Python newsgroup RPM (Old) tools to build RPMs SpecialBuilds.txt Describes extra symbols you can set for debug builds setuid-prog.c C helper program for set-uid Python scripts vgrindefs Python configuration for vgrind (a generic pretty printer)