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 belopolsky, loewis, tim.peters, vstinner
Date 2014-08-02.14:35:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
Le samedi 2 août 2014, Martin v. Löwis <> a écrit :
> What problem does this solve?

My patch detects overflows which are not detected yet. Currently i guess
that the behaviour on overflow is undefined. I should test each function.

I also want a nanosecond resolution. It's the same motivation than the PEP
410, except that the patch doesn't touch the Python API, I only care of the
C code which has fewer constraints (we don't need a "full" API). I expect
that C code is more concerned by the resolution because C code is faster.
You need to recompute timeout on EINTR (see the PEP 475 which is still a
draft). I don't want to loose precision and I want to round correctly.

My main usecase is to compute a timeout from two timestamps of a monotonic

IMO it's better to use PyTimeSpec structure everywhere to reuse the code
which is now well tested (by unit tests) and make the code more consistent.
For example, the datetime module rounds currently using the "down" method,
whereas it needs to round "floor" in fact. I saw this issue when I changed
the code to use PyTimeSpec in all functions.

I agree that my patch is large, especially the new code in pytime.c. I
would like to hide the complexity in functions, the API should be
simple. Do you think that changes in modules like time, socket or select
make the code more complex? I don't know if it's worth it.
Date User Action Args
2014-08-02 14:35:27vstinnersetrecipients: + vstinner, tim.peters, loewis, belopolsky
2014-08-02 14:35:27vstinnerlinkissue22117 messages
2014-08-02 14:35:26vstinnercreate