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