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.
least as big as a long. I believe this to be a safe assumption that is being
made in many parts of CPython, but a check could be added.
len(xrange(sys.maxint)) works now, so fix the testsuite's odd exception for
64-bit platforms too. It also fixes 'zip(xrange(sys.maxint), it)' as a
portable-ish (if expensive) alternative to enumerate(it); since zip() now
calls len(), this was breaking on (real) 64-bit platforms. No additional
test was added for that behaviour.
- The buildbot "fetch it" step failed at the end, due to
using Unix syntax in the final "copy the DLL" step.
test_sqlite was skipped as a result.
- test_sqlite is no longer an expected skip on Windows.
Re-enable all the tests in test_trace.py except one. Still not sure that these tests test what they used to test, but they pass. One failing test seems to be caused by undocumented line number table behavior in Python 2.4.
tracing/line number table in except blocks.
Reflow long lines introduced by col_offset changes. Update test_ast
to handle new fields in excepthandler.
As note in Python.asdl says, we might want to rethink how attributes
are handled. Perhaps they should be the same as other fields, with
the primary difference being how they are defined for all types within
a sum.
Also fix asdl_c so that constructors with int fields don't fail when
passed a zero value.
converted to CR CR NL. There may be a way to fix this with tcsetattr,
but I couldn't find it. There was a similar problem on IRIX.
Just normalize the output and compare that.
Will backport.
like cause the interpreter to exit abruptly. If there's a way to fix this,
it would be good to really fix it. It could just be the operation of the
std C library and we just aren't supposed to do that.
When the test case is skipped, we print a message so the user can check
for themselves.
This is based on pysqlite2.1.3, and provides a DB-API interface in
the standard library. You'll need sqlite 3.2.2 or later to build
this - if you have an earlier version, the C extension module will
not be built.
we are about to leave behind. An example of the cause of this leak can be
found in the leakers directory, in case we ever want to tackle the
underlying problem.
effect at the time test_decimal was imported. Else
running test_decimal had the bad side effect of
permanently changing the decimal context in effect.
That caused text_tokenize to fail if it ran after
test_decimal.
- The doctests in decistmt() weren't run at all when
test_tokenize was run via regrtest.py.
- Some expected output in decistmt() was Windows-specific
(but nobody noticed because the doctests weren't getting
run).
- test_roundtrip() didn't actually test anything when
running the tests with -O. Now it does.
- Changed test_roundtrip() to show the name of the input
file when it fails. That would have saved a lot of
time earlier today.
- Added a bunch of comments.
adds the following API calls: PySet_Clear(), _PySet_Next(), and
_PySet_Update(). The latter two are considered non-public. Tests and
documentation (for the public API) are included.
itertools.tee->instance->attribute->itertools.tee and
itertools.tee->teedataobject->itertools.tee cycles, which can be found now
that itertools.tee and its teedataobject participate in GC, remain findable
and cleanable. The test won't fail when they aren't, but at least the
frequent hunt-refleaks runs would spot the rise in refleaks.
def foo((x)): was getting recognized as requiring tuple unpacking
which is not correct.
Add tests for this case and the proper way to unpack a tuple of one:
def foo((x,)):
test_inpsect was incorrect before. I'm not sure why it was passing,
but that has been corrected with a test for both functions above.
This means the test (and therefore inspect.getargspec()) are broken in 2.4.
that yields after a throw(). Make @contextmanager not reraise
exceptions, but return a false value in that case instead. Add test
cases for both behaviors.
as diagnosed by Nick Coghlan.
test_capi.py: A test module should never spawn a thread as
a side effect of being imported. Because this one did, the
segfault one of its thread tests caused didn't occur until
a few tests after test_regrtest.py thought test_capi was
finished. Repair that. Also join() the thread spawned
at the end, so that test_capi is truly finished when
regrtest reports that it's done.
_testcapimodule.c test_thread_state(): this spawns a
couple of non-threading.py threads, passing them a PyObject*
argument, but did nothing to ensure that those threads
finished before returning. As a result, the PyObject*
_could_ (although this was unlikely) get decref'ed out of
existence before the threads got around to using it.
Added explicit synchronization (via a Python mutex) so
that test_thread_state can reliably wait for its spawned
threads to finish.
This was a fair amount of rework of the patch. Refactored test_fork1 so it
could be reused by the new tests for wait3/4. Also made them into new style
unittests (derive from unittest.TestCase).
This patch adds a-LAW encoding to audioop and replaces the old
u-LAW encoding/decoding code with the current code from sox.
Possible issues: the code from sox uses int16_t.
Code by Lars Immisch
of tuple) that provides incremental decoders and encoders (a way to use
stateful codecs without the stream API). Functions
codecs.getincrementaldecoder() and codecs.getincrementalencoder() have
been added.
Since it's never intended that this script be run by
regrtest.py, it shouldn't have been named with a "test_"
prefix to begin with. A consequence is that we shouldn't
see useless:
test_hashlib_speed skipped -- not a unit test (stand alone benchmark)
lines in regrtest output anymore.
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.
Tim Peters
Phillip J. Eby
Anthony Baxter
Neal Norwitz
Thomas Heller
Thomas Wouters
Jeremy Hylton
Martin v. Löwis
Georg Brandl
Fred Drake
Walter Dörwald
Barry Warsaw
Armin Rigo
Raymond Hettinger
Hye-Shik Chang
Trent Mick
Nick Coghlan
Guido van Rossum