"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.

failing on one of the 32-bit buildbot boxes because of it,
due to tempting but always-wrong Python code.  Users
probably have code like this too (I know I did ...).

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!

that are suspended outside of any try/except/finally blocks to be
garbage collected even if they are part of a cycle.  Generators that
suspend inside of an active try/except or try/finally block (including
those created by a ``with`` statement) are still not GC-able if they
are part of a cycle, however.

Introduce _child_active member to keep track on whether a child
needs to be waited for.
Backport candidate.

--enable-shared. Fixes #832799.

Fix warning about ptsname not being a prototype on Solaris.  Is this prototype even necessary anymore?

This was the result of inconsistent use of PyMem_* and PyObject_* allocators.
By changing to use PyObject_* allocator almost everywhere, this removes
the inconsistency.

on Alpha (and possibly other platforms) by using Py_CHARMASK().

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.