| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"x86 OpenBSD trunk" buildbot due to changing Python so that
Python-exposed addresses are always non-negative.
test_int_pointer_arg(): This line failed now whenever the
box happened to assign an address to `ci` "with the sign
bit set":
self.failUnlessEqual(addressof(ci), func(byref(ci)))
The problem is that the ctypes addressof() inherited "all
addresses are non-negative now" from changes to
PyLong_FromVoidPtr(), but byref() did not inherit that
change and can still return a negative int.
I don't know whether, or what, the ctypes implementation wants
to do about that (possibly nothing), but in the meantime
the test fails frequently.
So, introduced a Python positive_address() function in
the test module, that takes a purported machine address and,
if negative, converts it to a non-negative value "with the
same bits". This should leave the test passing under all
versions of Python.
Belated thanks to Armin Rigo for teaching me the sick trick ;-)
for determining the # of bits in a machine pointer via abuse
of the struct module.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
test. Add some lines that at least invoke the default
__hash__, although there's nothing to check there beyond
that they don't blow up.
|
|
|
|
|
| |
to work correctly with modules imported from zipfiles or via other PEP 302
__loader__ objects. Tests and doc updates are included.
|
|
|
|
| |
didn't commit it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
| |
due to that id() may return a long on a 32-bit box now. On a box that
assigns addresses "with the sign bit set", id() always returns a long now.
|
|
|
|
|
| |
to that id() may return a long on a 32-bit box now. On a box that assigns
addresses "with the sign bit set", id() always returns a long now.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
it was being run, but no tests were actually executed!
|
| |
|
|
|
|
|
|
| |
Introduce _child_active member to keep track on whether a child
needs to be waited for.
Backport candidate.
|
|
|
|
| |
--enable-shared. Fixes #832799.
|
| |
|
|
|
|
|
|
| |
to load extension modules and now provides the dl module. As a result,
sys.setdlopenflags() now works correctly on these systems. (SF patch
#1454844)
|
| |
|
| |
|
| |
|
|
|
|
| |
why this breaks on openbsd sometimes.
|
|
|
|
| |
in 2.4, so put it back. The string in telnetlib looks like a comment.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Also adds some backwards compatibility when compiling _bsddb.c on earlier
python versions (needed for pybsddb).
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
If RTLD_LOCAL is not #defined in any header file (Windows), set it to 0.
If RTLD_GLOBAL is not #defined, set it equal to RTLD_LOCAL.
This should fix ctypes on cygwin.
|
| |
|
|
|
|
| |
will backport.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
version this should support is Python 2.3
|
| |
|
|
|
|
| |
Klose.
|
| |
|
| |
|
| |
|
|
|
|
| |
os.startfile is not present.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
is 'python'. But 'python' is actually a directory, 'python.exe' is the
executable.
|
|
|
|
|
|
|
|
| |
- 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.
|
| |
|
| |
|