For whatever reason I cannot build rustapi_module without this, and
rather than figure out the core problem, I figured that, for symmetry,
it makes sense to just implement Debug for PyObject.
These were basically cargo culted from lazy_static's implementation, but
they are not idiomatic or necessary to indicate that these are private
variables.
Because the PyDateTime_CAPI is always accessed via a lazy-initialized
static reference, it is not necessary to handle the case where the
functions on the C struct have not been initialized.
It *should* be safe to cast u32 to i32 in the case of the Py{Date}{Time}
constructors, because any unsigned values that would overflow would
raise an error anyway.
This adds tests to ensure that this is the case - they currently fail on
Python <3.6 because of a known issue with the Python C API.
As noted in the comments, using call_once to initialize the
PyDateTimeAPI singleton is causing deadlocks with the GIL; these
deadlocks can be avoided by falling back on CPython's own locking
behavior.
Most of the datetime related changes were made before pyo3 switched to
using rustfmt, so I ran rustfmt only on the final commit to make it
easier to rewrite history as necessary (for fixups and whatnot).
The bounds checking tests are xfail because the datetime "fast path"
constructor didn't do bounds checking until bpo-29100 was resolved in
CPython commit b67f0967386a9c90411, which was merged for Python 3.6.
This functionality should be simple to backport to earlier versions in a
future commit.
BPO issue:
https://bugs.python.org/issue29100
CPython commit:
b67f096738
Paul Ganssle