This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Mariatta, danielhrisca, docs@python, eryksun, kh90909, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
Date 2020-11-16.15:13:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1605539582.17.0.487811171453.issue37205@roundup.psfhosted.org>
In-reply-to
Content
I close the issue, it's now fixed in master. Thanks for the bug report Ken Healy.


While Python 3.8 and 3.9 are also affected, I prefer to leave them unchanged to avoid bad surprises during a minor update (3.x.y bugfix release). If you disagree, please speak up!


The regression was introduced in Python 3.7 by:

commit bdaeb7d237462a629e6c85001317faa85f94a0c6
Author: Victor Stinner <victor.stinner@gmail.com>
Date:   Mon Oct 16 08:44:31 2017 -0700

    bpo-31773: _PyTime_GetPerfCounter() uses _PyTime_t (GH-3983)
    
    * Rewrite win_perf_counter() to only use integers internally.
    * Add _PyTime_MulDiv() which compute "ticks * mul / div"
      in two parts (int part and remaining) to prevent integer overflow.
    * Clock frequency is checked at initialization for integer overflow.
    * Enhance also pymonotonic() to reduce the precision loss on macOS
      (mach_absolute_time() clock).

This change was related to the implementation of the PEP 564.

If you are curious about this work, I wrote two articles:

* https://vstinner.github.io/python37-pep-564-nanoseconds.html
* https://vstinner.github.io/python37-perf-counter-nanoseconds.html
* https://vstinner.github.io/pytime.html
History
Date User Action Args
2020-11-16 15:13:02vstinnersetrecipients: + vstinner, paul.moore, tim.golden, docs@python, zach.ware, eryksun, steve.dower, Mariatta, danielhrisca, kh90909
2020-11-16 15:13:02vstinnersetmessageid: <1605539582.17.0.487811171453.issue37205@roundup.psfhosted.org>
2020-11-16 15:13:02vstinnerlinkissue37205 messages
2020-11-16 15:13:01vstinnercreate