Tim found that once test_longexp has run, test_sort takes very much
longer to run than normal. A profiler run showed that this was due to
PyFrame_New() taking up an unreasonable amount of time. A little
thinking showed that this was due to the while loop clearing the space
available for the stack. The solution is to only clear the local
variables (and cells and free variables), not the space available for
the stack, since anything beyond the stack top is considered to be
garbage anyway. Also, use memset() instead of a while loop counting
backwards. This should be a time savings for normal code too! (By a
probably unmeasurable amount. :-)
Fred Drake [Tue, 30 Jul 2002 17:52:05 +0000 (17:52 +0000)]
SF patch #581414: info reader bug
The "Matching vs. Searching" Info node is unreachable from the Info
program (but is fine in Emacs's Info mode). This patch seems to fix
it. This is the only occurrence where the info reader fails, so
probably it could be addressed in the python docs as a workaround.
Forwarded the report to the info maintainer.
Fred Drake [Thu, 25 Jul 2002 21:11:41 +0000 (21:11 +0000)]
Small clarifications when referring to the sys.exc_* variables so that
readers are not given the wrong impression that they should be using those
on a regualar basis.
This closes SF bug #585598.
Tim Peters [Tue, 16 Jul 2002 20:09:08 +0000 (20:09 +0000)]
The atexit module effectively turned itself off if sys.exitfunc already
existed at the time atexit first got imported. That's a bug, and this
fixes it.
Also reworked test_atexit.py to test for this too, and to stop using
an "expected output" file, and to test what actually happens at exit
instead of just simulating what it thinks atexit will do at exit.
Jeremy Hylton [Tue, 16 Jul 2002 19:42:21 +0000 (19:42 +0000)]
The object returned by tp_new() may not have a tp_init.
If the object is an ExtensionClass, for example, the slot is not even
defined. So we must check that the type has the slot (implied by
HAVE_CLASS) before calling tp_init().
The test of httplib makes it difficult to maintain httplib. There are
two many idioms that pyclbr doesn't seem to understand, and I don't
understand how to update these tests to make them work.
Jeremy Hylton [Fri, 12 Jul 2002 14:23:43 +0000 (14:23 +0000)]
Backport changes.
Change _begin() back to begin().
Fix for SF bug 579107.
Fix for SF bug #432621: httplib: multiple Set-Cookie headers
Fix SF bug #575360
Handle HTTP/0.9 responses.
Tim Peters [Mon, 8 Jul 2002 22:30:52 +0000 (22:30 +0000)]
SF bug 578752: COUNT_ALLOCS vs heap types
Repair segfaults and infinite loops in COUNT_ALLOCS builds in the
presence of new-style (heap-allocated) classes/types.
Note: test_gc fails in a COUNT_ALLOCS build now, because it expects
a new-style class to get garbage collected.
Tim Peters [Mon, 8 Jul 2002 19:35:56 +0000 (19:35 +0000)]
PyNode_AddChild(): Backporting an aggressive over-allocation policy
when a parse node grows a very large number of children. This sidesteps
platform realloc() disasters on several platforms.
Fred Drake [Tue, 2 Jul 2002 22:35:02 +0000 (22:35 +0000)]
Update the documentation of the errors and failures attributes of the
TestResult object. Add an example of how to get even more information for
apps that can use it.
Closes SF bug #558278.
Tim Peters [Sun, 30 Jun 2002 18:48:53 +0000 (18:48 +0000)]
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
Fred Drake [Tue, 25 Jun 2002 17:18:48 +0000 (17:18 +0000)]
[Backport of recent changes to the SAX documentation.]
Add more links to the "See also" section for the xml.sax package.
Talk about interfaces rather than implementation classes where appropriate.
Add hyperlinks to make the documentation on the Attributes and AttributesNS
interfaces more discoverable.
Closes SF bug #484603.
Guido van Rossum [Tue, 18 Jun 2002 16:46:57 +0000 (16:46 +0000)]
Backport:
Patch from SF bug 570483 (Tim Northover).
In a fresh interpreter, type.mro(tuple) would segfault, because
PyType_Ready() isn't called for tuple yet. To fix, call
PyType_Ready(type) if type->tp_dict is NULL.
Fred Drake [Fri, 14 Jun 2002 14:36:23 +0000 (14:36 +0000)]
Clean up descriptions of PyObject_RichCompare() and PyObject_RichCompareBool()
based on comments from David Abrahams.
Added refcount information for these functions.
Guido van Rossum [Fri, 14 Jun 2002 02:28:23 +0000 (02:28 +0000)]
Backport:
Inexplicably, recurse_down_subclasses() was comparing the object
gotten from a weak reference to NULL instead of to None. This caused
the following assert() to fail (but only in 2.2 in the debug build --
I have to find a better test case).
Guido van Rossum [Thu, 13 Jun 2002 21:36:35 +0000 (21:36 +0000)]
Backport:
Fix for SF bug 532646. This is a little simpler than what Neal
suggested there, based upon a better analysis (__getattr__ is a red
herring).
[This might be a 2.1 bugfix candidate we well, if people care]
Guido van Rossum [Wed, 12 Jun 2002 03:48:46 +0000 (03:48 +0000)]
Backport:
SF bug 567538: Generator can crash the interpreter (Finn Bock).
This was a simple typo. Strange that the compiler didn't catch it!
Instead of WHY_CONTINUE, two tests used CONTINUE_LOOP, which isn't a
why_code at all, but an opcode; but even though 'why' is declared as
an enum, comparing it to an int is apparently not even worth a
warning -- not in gcc, and not in VC++. :-(
Fred Drake [Tue, 11 Jun 2002 02:57:32 +0000 (02:57 +0000)]
Completely revise markup for the list of list methods; the new markup matches
the semantics and presentation used in the library reference.
Added an explanation of the use of [...] to denote optional arguments, since
this is the only use of this in a signature line.
Closes SF bug #567127.
Guido van Rossum [Mon, 10 Jun 2002 21:37:00 +0000 (21:37 +0000)]
Backport:
SF patch 560794 (Greg Chapman): deepcopy can't handle custom
metaclasses.
This is essentially the same problem as that reported in bug 494904
for pickle: deepcopy should treat instances of custom metaclasses the
same way it treats instances of type 'type'.
Guido van Rossum [Mon, 10 Jun 2002 16:02:44 +0000 (16:02 +0000)]
Backport two patches that belong together:
(2.150)
In the recent python-dev thread "Bizarre new test failure", we
discovered that subtype_traverse must traverse the type if it is a
heap type, because otherwise some cycles involving a type and its
instance would not be collected. Simplest example:
while 1:
class C(object): pass
C.ref = C()
This program grows without bounds before this fix. (It grows ever
slower since it spends ever more time in the collector.)
Simply adding the right visit() call to subtype_traverse() revealed
other problems. With MvL's help we re-learned that type_clear()
doesn't have to clear *all* references, only the ones that may not be
cleared by other means. Careful analysis (see comments in the code)
revealed that only tp_mro needs to be cleared. (The previous checkin
to this file adds a test for tp_mro==NULL to _PyType_Lookup() that's
essential to prevent crashes due to tp_mro being NULL when
subtype_dealloc() tries to look for a __del__ method.) The same kind
of analysis also revealed that subtype_clear() doesn't need to clear
the instance dict.
With this fix, a useful property of the collector is once again
guaranteed: a single gc.collect() call will clear out all garbage.
(It didn't always before, which put us on the track of this bug.)
(2.151)
Undo the last chunk of the previous patch, putting back a useful
assert into PyType_Ready(): now that we're not clearing tp_dict, we
can assert that it's non-NULL again.