PyStringData comments mention wanting to receive interpreter-
specific unicode types. I tried implementing this, but it's
more complex and slower to call libpython to fill a buffer
of u32 or such and convert that in Rust using widestring.
This implementation receives UTF-8 from PyUnicode_AsUTF8AndSize()
in python3 and PyUnicode_AsUTF8String() in python2. PyStringData
is removed as unnecessary.
The data() method on PyString, PyBytes, and PyUnicode is
replaced with as_bytes().
The python2 API changes improve the performance of
extracting unicode strings.
The backticks properly monospace the Python expressions in the rendered
docs, and also escape square brackets inside so that rustdoc isn't
trying to parse them as references.
This test previously relied on a stable reference count for None, which
is not likely to be true in multi-threaded code. This creates an object
specifically for the test to avoid race conditions.
I've just seen that this had been hidden from clippy through the ffi module reordering, but fixing this on master would cause merge conflicts, so I'm fixing this here directly
Because it's unlikely that anything other than the `year` parameter will
change in the C Python API, the rest can be restricted to their logical
ranges, which improves the compile-time error checking.
While the valid ranges for the constructor parameters is the same when
expressed as either u32 or i32, since the Python API uses i32 in their
public interface, we won't have to make any changes to the signatures if
the Python behavior changes (e.g. supporting negative years) without
their API changing.
This more closely mimics the CPython API, since the import logic
populates the global, it should also populate the cache.
This also allows users to eagerly initialize the Python C API if
preferred (for example, doing so before populating a bunch of threads,
or before making performance measurements that will be thrown off by a
lazy import).
kngwyu