- 09 Nis, 2003 18 kayıt (commit)
-
-
Guido van Rossum yazdı
- CHECK_VALID() was checking the wrong value for a closed fd - fseek(&_iob[fileno], ...) doesn't work for fileno >= 20
-
Guido van Rossum yazdı
exceptionally large totals etc.
-
Guido van Rossum yazdı
recursively. - pdb has a new command, "debug", which lets you step through arbitrary code from the debugger's (pdb) prompt.
-
Fred Drake yazdı
-
Guido van Rossum yazdı
-
Guido van Rossum yazdı
of saying x->ob_type.
-
Andrew M. Kuchling yazdı
-
Guido van Rossum yazdı
typecheck that guarantees it's a string, and BTW string subclasses could hide references.
-
Jason Tishler yazdı
Currently, the cygwinccompiler.py compiler handling in distutils is invoking the cygwin and mingw compilers with the -static option. Logically, this means that the linker should choose to link to static libraries instead of shared/dynamically linked libraries. Current win32 binutils expect import libraries to have a .dll.a suffix and static libraries to have .a suffix. If -static is passed, it will skip the .dll.a libraries. This is pain if one has a tree with both static and dynamic libraries using this naming convention, and wish to use the dynamic libraries. The -static option being passed in distutils is to get around a bug in old versions of binutils where it would get confused when it found the DLLs themselves. The decision to use static or shared libraries is site or package specific, and should be left to the setup script or to command line options.
-
Jack Jansen yazdı
-
Jack Jansen yazdı
-
Andrew M. Kuchling yazdı
-
Fred Drake yazdı
-
Fred Drake yazdı
-
Anthony Baxter yazdı
-
Fred Drake yazdı
-
Skip Montanaro yazdı
-
Skip Montanaro yazdı
-
- 08 Nis, 2003 11 kayıt (commit)
-
-
Jeremy Hylton yazdı
If a class was defined inside a function, used a static or class method, and used super() inside the method body, it would be caught in an uncollectable cycle. (Simplified version: The static/class method object would point to a function object with a closure that referred to the class.) Bugfix candidate.
-
Just van Rossum yazdı
when DST began.
-
Skip Montanaro yazdı
-
Skip Montanaro yazdı
-
Tim Peters yazdı
These never failed in 2.3, and the tests confirm it. They still blow up in the 2.2 branch, despite that all the gc-vs-__del__ fixes from 2.3 have been backported (and this is expected -- 2.2 needs more work than 2.3 needed).
-
Skip Montanaro yazdı
-
Tim Peters yazdı
-
Fred Drake yazdı
Based on a suggestion from a reader.
-
Fred Drake yazdı
-
Tim Peters yazdı
-
Tim Peters yazdı
cases, wrote docs, added a test.
-
- 07 Nis, 2003 5 kayıt (commit)
-
-
Tim Peters yazdı
-
Tim Peters yazdı
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).
-
Tim Peters yazdı
out whether __del__ exists, without executing any Python-level code.
-
Anthony Baxter yazdı
-
Anthony Baxter yazdı
-
- 06 Nis, 2003 6 kayıt (commit)
-
-
Tim Peters yazdı
-
Tim Peters yazdı
instead of looping. Smaller and clearer. Faster, too, when we're not appending to gc.garbage: gc_list_merge() takes constant time, regardless of the lists' sizes. append_objects(): Moved up to live with the other list manipulation utilities.
-
Raymond Hettinger yazdı
mwh pointed out that the error message did not make sense if obtained by rearranging the bases.
-
Raymond Hettinger yazdı
-
Tim Peters yazdı
take no arguments; cuts generated code size.
-
Tim Peters yazdı
externally unreachable objects with finalizers, and externally unreachable objects without finalizers reachable from such objects. This allows us to call has_finalizer() at most once per object, and so limit the pain of nasty getattr hooks. This fixes the failing "boom 2" example Jeremy posted (a non-printing variant of which is now part of test_gc), via never triggering the nasty part of its __getattr__ method.
-