man pages suggest that the proper thing to do is to add THR_NEW_LWP to
the flags on thr_create(), and that there really isn't a downside, so
I'll do that.
"""
Spec says that on success pthread_create returns 0. It does not say
that an error code will be < 0. Linux glibc2 pthread_create() returns
ENOMEM (12) when one exceed process limits. (It looks like it should
return EAGAIN, but that's another story.)
For reference, see:
http://www.opengroup.org/onlinepubs/7908799/xsh/pthread_create.html
"""
[I have a feeling that similar bugs were fixed before; perhaps someone
could check that all error checks no check for != 0?]
xrange(), especially for platforms where int and long are different
sizes (so sys.maxint isn't actually the theoretical limit for the
length of a list, but the largest C int is -- sys.maxint is the
largest Python int, which is actually a C long).
test for classes with a __complex__() method. The attribute is pulled
out of the instance with PyObject_GetAttr() but this transfers
ownership and the function object was never DECREF'd.
v temporary variable was never decref'd. Test this by starting up the
interpreter, hitting C-c, then immediately exiting.
Same potential leak can occur if error is E_NOMEM, since the return is
done in the case block. Added Py_XDECREF(v); to both blocks, just
before the return.
