Change test_functions.py so that it can be run multiple time without
failing: Assign a restype to the function in test_intresult, and move
the definition of class POINT to module level so that no new class is
created each time the test is run.
between a TestCase instance, the database it opened (or a cursor to a
database) and a bound method as a registered database callback, and a lack
of GC-handling in bsddb caused the TestCases to linger. Fix the test, for
now, as backward compatibility makes adding GC to bsddb annoying.
Anyway, this is the changes to the with-statement
so that __exit__ must return a true value in order
for a pending exception to be ignored.
The PEP (343) is already updated.
an error code, this let `self` leak. This is a disaster
on Windows, since `self` already points to a newly-opened
file object, and it was impossible for Python code to
close the thing since the only reference to it was in a
blob of leaked C memory.
test_hotshot test_bad_sys_path(): This new test provoked
the C bug above. This test passed, but left an open
"@test" file behind, which caused a massive cascade of
bogus test failures in later, unrelated tests on Windows.
Changed the test code to remove the @test file it leaves
behind, which relies on the change above to close that
file first.
The failure definitely seems timing related. This change *seems* to work.
Since the failure isn't doesn't occur consistently, it's hard to tell.
Running these tests on Solaris in this order:
test_urllibnet test_operator test_cgi \
test_isinstance test_future test_ast test_logging
generally caused a failure (about 50% of the time) before the sleep.
I couldn't provoke the failure with the sleep.
This should really be cleaned up by using threading.Events or something
so it is not timing dependent and doesn't hang forever on failure.
test_codecmaps_tw test_importhooks test_socket_ssl
I don't completely understand the cause, but there's a lot of import magic
going on and this is the smallest change which fixes the problem.
want to wait forever if we don't receive the last message. But we also
don't want the test to fail if we shutdown too quickly. I can't reliably
reproduce this failure, so I'm kinda guessing this is the problem.
We'll see if this band-aid helps.
- regenerate ast.py
- add future flags for absolute-import and with-statement so they
(hopefully) properly get set in code-object flags
- try out if/else expressions in actual code for the hell of it.
Seems to generate the same kind of bytecode as the normal compiler.
The culprit was an expression-less yield -- the first apparently in
the standard library. I added a unit test for this.
Also removed the hack to force compilation of test_with.py.
Nick Coghlan
Thomas Heller
Hye-Shik Chang
Thomas Wouters
Tim Peters
Martin v. Löwis
Guido van Rossum
Georg Brandl
Neal Norwitz
Andrew M. Kuchling
Barry Warsaw
Walter Dörwald
Brett Cannon