Overflow test in test_FromSecondsObject() fails on FreeBSD 10.0 buildbot which
uses clang. clang implements more aggressive optimization which gives
different result than GCC on undefined behaviours.
Check if a multiplication will overflow, instead of checking if a
multiplicatin had overflowed, to avoid undefined behaviour.
Add also debug information if the test on overflow fails.
* Filter values which would overflow on conversion to the C long type
(for timeval.tv_sec).
* Adjust also the message of OverflowError on PyTime conversions
* test_time: add debug information if a timestamp conversion fails
Drop all hardcoded tests. Instead, reimplement each function in Python, usually
using decimal.Decimal for the rounding mode.
Add much more values to the dataset. Test various timestamp units from
picroseconds to seconds, in integer and float.
Enhance also _PyTime_AsSecondsDouble().
datetime.datetime now round microseconds to nearest with ties going to nearest
even integer (ROUND_HALF_EVEN), as round(float), instead of rounding towards
-Infinity (ROUND_FLOOR).
pytime API: replace _PyTime_ROUND_HALF_UP with _PyTime_ROUND_HALF_EVEN. Fix
also _PyTime_Divide() for negative numbers.
_PyTime_AsTimeval_impl() now reuses _PyTime_Divide() instead of reimplementing
rounding modes.
Issue #24891: Fix a race condition at Python startup if the file descriptor
of stdin (0), stdout (1) or stderr (2) is closed while Python is creating
sys.stdin, sys.stdout and sys.stderr objects. These attributes are now set
to None if the creation of the object failed, instead of raising an OSError
exception. Initial patch written by Marco Paolini.
Don't check anymore at runtime that the monotonic clock doesn't go backward.
Yes, it happens. It occurs sometimes each month on a Debian buildbot slave
running in a VM.
The problem is that Python cannot do anything useful if a monotonic clock goes
backward. It was decided in the PEP 418 to not fix the system, but only expose
the clock provided by the OS.
with ties going away from zero (ROUND_HALF_UP), as Python 2 and Python older
than 3.3, instead of rounding to nearest with ties going to nearest even
integer (ROUND_HALF_EVEN).
See the latest version of getrandom() manual page:
http://man7.org/linux/man-pages/man2/getrandom.2.html#NOTES
The behavior when a call to getrandom() that is blocked while reading from
/dev/urandom is interrupted by a signal handler depends on the
initialization state of the entropy buffer and on the request size, buflen.
If the entropy is not yet initialized, then the call will fail with the
EINTR error. If the entropy pool has been initialized and the request size
is large (buflen > 256), the call either succeeds, returning a partially
filled buffer, or fails with the error EINTR. If the entropy pool has been
initialized and the request size is small (buflen <= 256), then getrandom()
will not fail with EINTR. Instead, it will return all of the bytes that
have been requested.
Note: py_getrandom() calls getrandom() with flags=0.
Benjamin Peterson
Victor Stinner
Steve Dower
Serhiy Storchaka
Larry Hastings
Yury Selivanov
Eric V. Smith
Raymond Hettinger
Brett Cannon
Robert Collins
Berker Peksag
Stefan Krah