not be tracked by GC. This fixes 254 of test_generators' refleaks on my
machine, but I'm sure something else will make them come back :>
Not adding a separate test for this kind of cycle, since the existing
fib/m235 already test them in more extensive ways than any 'minimal' test
has been able to manage.
examples no longer require any explicit closing to avoid
leaking.
That the tee-based examples still do is (I think) still a
mystery. Part of the mystery is that gc.garbage remains
empty: if it were the case that some generator in a trash
cycle said it needed finalization, suppressing collection
of that cycle, that generator _would_ show up in gc.garbage.
So this is acting more like, e.g., some tp_traverse slot
isn't visiting all the pointers it should (in which case
the skipped pointer(s) would act like an external root,
silently suppressing collection of everything reachable
from it(them)).
problems: first, PyGen_NeedsFinalizing() had an off-by-one bug that
prevented it from ever saying a generator didn't need finalizing, and
second, frame objects cleared themselves in a way that caused their
owning generator to think they were still executable, causing a double
deallocation of objects on the value stack if there was still a loop
on the block stack. This revision also removes some unnecessary
close() operations from test_generators that are now appropriately
handled by the cycle collector.
an incremental encoder that must retain part of the data between calls
to the encode() method.
Fix the incremental encoder and decoder for the IDNA encoding.
This closes SF patch #1453235.
The test case came from test_generators, not test_itertools.
Ensure there's no cyclic garbage we are counting.
This is weird because it leaks, then reaches a limit:
python.exe -i test_tee.py
>>> leak()
0
[26633 refs]
>>> leak()
0
[26658 refs]
>>> leak()
0
[26683 refs]
>>> leak()
0
[26708 refs]
>>> leak()
0
[26708 refs]
>>> leak()
0
[26708 refs]
>>> leak()
0
appear. Get rid of them by nuking doctest's default DocTestRunner
instance as part of cleanup(). Also cleanup() before running the
first test repetition (the test was run once before we get into
the -R branch).
This may be causing the debian sparc buildbot to fail.
Print a little message to let the user ^w buildbot know it's still thinking.
We may want to adjust the time period which is currently 5 minutes.
Will backport.
prepends the exception's module name to non-builtin exceptions, like
the interpreter itself does.
broke a number of doctests. should be discussed before checking in (see
discussion on python-dev).
bsddb.*open() methods cachesize parameter wouldn't work (raised an
internal bsddb.db exception when it was given). The set_cachesize
call needed to be moved from the DB object to the DBEnv since the env
was introduced to allow for threading.
(will backport to 2.4)
Using None for a filename with the 'n' flag when calling bsddb.btopen
would cause an error while checking if the file None existed. error
not likely to be seen as anyone using None for a filename would likely
use the 'c' flag in the first place.
tests. Alas, because only the "x86 OpenBSD trunk" buildbot fails
these tests, and test_descr stops after the first failure, there's
no sane way for me to fix these short of fixing one and then
waiting for the buildbot to reveal the next one.
to that id() can now return a Python long on a 32-bit box that allocates
addresses "with the sign bit set".
test_set.py test_subclass_with_custom_hash(): it's never been portably
legal for a __hash__() method to return id(self), but on 32-bit boxes
that never caused a problem before it became possible for id() to
return a Python long. Changed __hash__ here to return a Python int
regardless of platform.
test_descr.py specials():
vereq(hash(c1), id(c1))
has never been a correct test -- just removed it (hash() is always
a Python int; id() may be a Python long).
default decimal context, causing test_tokenize to fail
if it ran after test_contextlib. Changed to restore
the decimal context in effect at the test's start.
soon after because the gmail address it connects to started timing
out on all the buildbot slaves. Rewrote the test to produce a
warning message (instead of failing) when the address times out.
Also removed the special case for Windows -- this test started to
work on Windows as soon as bug 1462352 was fixed.
mouse events. This makes the test fail. Catch that case and don't run
the tests. Should make the debian/ubuntu buildbots that run in a chroot
work again.
Will backport to release24-maint.
Thomas Wouters
Tim Peters
Phillip J. Eby
Walter Dörwald
Armin Rigo
Neal Norwitz
Georg Brandl
Anthony Baxter
Gregory P. Smith
Thomas Heller