Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Yay! Record time from acceptance to implementation. :-) On Thu, Nov 2, 2017 at 8:16 AM, Victor Stinner wrote: > Thank you Guido for your review and approval. > > I just implemented the PEP 564 and so changed the PEP status to Final. > > FYI I also added 3 new clock

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Thank you Guido for your review and approval. I just implemented the PEP 564 and so changed the PEP status to Final. FYI I also added 3 new clock identifiers to the time module in Python 3.7: CLOCK_BOOTTIME, CLOCK_PROF and CLOCK_UPTIME. So you can now get your Linux uptime with a resolution of

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On 10/30/2017 10:18 AM, Guido van Rossum wrote: I have read PEP 564 and (mostly) followed the discussion in this thread, and I am happy with the PEP. I am hereby approving PEP 564. Congratulations Victor! Congrats, Victor! ___ Python-Dev mailing

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

I have read PEP 564 and (mostly) followed the discussion in this thread, and I am happy with the PEP. I am hereby approving PEP 564. Congratulations Victor! -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Hi David, On 10/22/2017 07:30 PM, David Mertz wrote: > The 'time' module is about > wall clock out calendar time, not about *simulation time*. means that the other scale direction makes more sense for the module? aka 'get_time('us'), get_time('ms'), 'get_time('s') Thanks, --francis

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Warning: the PEP 564 doesn't make any assumption about clock synchronizations. My intent is only to expose what the operating system provides without losing precision. That's all :-) 2017-10-24 13:25 GMT+02:00 Antoine Pitrou : > NTP is layered over UDP. The article shows base

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Le 24/10/2017 à 13:20, Victor Stinner a écrit : >> See https://blog.cloudflare.com/how-to-achieve-low-latency/ > > This article doesn't mention NTP, synchronization or nanoseconds. NTP is layered over UDP. The article shows base case UDP latencies of around 15µs over 10Gbps Ethernet. Regards

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

2017-10-24 11:22 GMT+02:00 Antoine Pitrou : > What does synchronization have to do with it? If synchronization > matters, then your PEP should be rejected, because current computers > using NTP can't synchronize with a better precision than 230 ns. Currently, the PEP 564 is

[Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On Tuesday, October 24, 2017, Antoine Pitrou > wrote: > On Tue, 24 Oct 2017 09:00:45 +0200 > Victor Stinner wrote: > > By the way, you mentionned that clocks are not synchronized. That's > another

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On Tue, 24 Oct 2017 09:00:45 +0200 Victor Stinner wrote: > By the way, you mentionned that clocks are not synchronized. That's another > revelant point. Even if system clocks are synchronized on a single > computer, I read that you cannot reach nanosecond resolution for

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Thanks Thomas, it was interesting! You confirmed that time.time_ns() and other system clocks exposed by Python are inappropriate for sub-nanosecond physical experiment. By the way, you mentionned that clocks are not synchronized. That's another revelant point. Even if system clocks are

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On Monday, October 23, 2017, Thomas Jollans wrote: > On 22/10/17 17:06, Wes Turner wrote: > > There are current applications with greater-than nanosecond precision: > > > > - relativity experiments > > - particle experiments > > > > Must they always use their own implementations of

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On 22/10/17 17:06, Wes Turner wrote: > There are current applications with greater-than nanosecond precision: > > - relativity experiments > - particle experiments > > Must they always use their own implementations of time., datetime. > __init__, fromordinal, fromtimestamp ?! > > -

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On Sun, Oct 22, 2017 at 1:42 PM, Wes Turner wrote: > Aligning simulation data in context to other events may be enlightening: > is there a good library for handing high precision time units in Python > (and/or CFFI)? > Well, numpy's datetime64 can be set to use (almost)

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Le 22 oct. 2017 17:06, "Wes Turner" a écrit : Must they always use their own implementations of time., datetime. __init__, fromordinal, fromtimestamp ?! Yes, exactly. Note: Adding resolution better than 1 us to datetime is not in the scope of the PEP but there is an

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On Sunday, October 22, 2017, David Mertz wrote: > I worked at a molecular dynamics lab for a number of years. I advocated > switching all our code to using attosecond units (rather than fractional > picoseconds). > > However, this had nothing whatsoever to do with the machine

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

I worked at a molecular dynamics lab for a number of years. I advocated switching all our code to using attosecond units (rather than fractional picoseconds). However, this had nothing whatsoever to do with the machine clock speeds, but only with the physical quantities represented and the

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On 23 October 2017 at 01:06, Wes Turner wrote: > On Saturday, October 21, 2017, Nick Coghlan wrote: > >> So yeah, for nanosecond resolution to not be good enough for programs >> running in Python, we're going to be talking about some genuinely >>

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On Mon, Oct 23, 2017 at 2:06 AM, Wes Turner wrote: > What about bus latency (and variance)? I'm currently in Los Angeles. Bus latency is measured in minutes, and may easily exceed sixty of them. :| Seriously though: For applications requiring accurate representation of

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On Saturday, October 21, 2017, Nick Coghlan wrote: > On 22 October 2017 at 09:32, Victor Stinner > wrote: > >> Le 21 oct. 2017 20:31, "francismb" >

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Hi Victor, I made some small fixes to the PEP. As far as I'm concerned, the PEP is ok and should be approved :-) Regards Antoine. On Mon, 16 Oct 2017 12:42:30 +0200 Victor Stinner wrote: > Hi, > > While discussions on this PEP are not over on python-ideas, I

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On 22 October 2017 at 09:32, Victor Stinner wrote: > Le 21 oct. 2017 20:31, "francismb" a écrit : > > I understand that one can just multiply/divide the nanoseconds returned, > (or it could be a factory) but wouldn't it help for future enhancements

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Le 21 oct. 2017 20:31, "francismb" a écrit : I understand that one can just multiply/divide the nanoseconds returned, (or it could be a factory) but wouldn't it help for future enhancements to reduce the number of functions (the 'pico' question)? If you are me to predict

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

If it sounds as there is no need or is unnecessary to you then it its ok :-), thank you for the feedback ! I'm just curious on: On 10/21/2017 05:45 PM, Guido van Rossum wrote: > That sounds like unnecessary generality, Meaning that the selection of precision on running time 'costs'? I

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

That sounds like unnecessary generality, and also suggests that the API might support precisions way beyond what is realistic. On Sat, Oct 21, 2017 at 4:39 AM, francismb wrote: > Hi Victor, > > On 10/18/2017 01:14 AM, Victor Stinner wrote: > > I updated my PEP 564 to add

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Hi Victor, On 10/18/2017 01:14 AM, Victor Stinner wrote: > I updated my PEP 564 to add time.process_time_ns(): > https://github.com/python/peps/blob/master/pep-0564.rst > > The HTML version should be updated shortly: > https://www.python.org/dev/peps/pep-0564/ ** In practive, the resolution of

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

I updated my PEP 564 to add time.process_time_ns(): https://github.com/python/peps/blob/master/pep-0564.rst The HTML version should be updated shortly: https://www.python.org/dev/peps/pep-0564/ I better explained why some functions got a new nanosecond variant, whereas others don't. The

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Antoine Pitrou: > Why not ``time.process_time_ns()``? I measured the minimum delta between two clock reads, ignoring zeros. I tested time.process_time(), os.times(), resource.getrusage(), and their nanosecond variants (with my WIP implementation of the PEP 564). Linux: * process_time_ns(): 1 ns

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

> Since the ``time.clock()`` function was deprecated in Python 3.3, no > ``time.clock_ns()`` is added. FYI I just proposed a change to *remove* time.clock() from Python 3.7: https://bugs.python.org/issue31803 This change is not required by, nor directly related to, the PEP 564. Victor

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On Mon, 16 Oct 2017 19:20:44 +0200 Victor Stinner wrote: > Oh, now I'm confused. I misunderstood your previous message. I understood > that you changed you mind and didn't want to add process_time_ns(). > > Can you elaborate why you consider that time.process_time_ns()

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Oh, now I'm confused. I misunderstood your previous message. I understood that you changed you mind and didn't want to add process_time_ns(). Can you elaborate why you consider that time.process_time_ns() is needed, but not the nanosecond flavor of os.times() nor resource.getrusage()? These

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On Mon, 16 Oct 2017 18:53:18 +0200 Victor Stinner wrote: > 2017-10-16 18:28 GMT+02:00 Antoine Pitrou : > >> What do you think? > > > > It sounds fine to me! > > Ok fine, I updated the PEP. Let's start simple with the few functions > (5 "clock"

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Makes sense, thanks. -Ben On Mon, Oct 16, 2017 at 12:28 PM, Victor Stinner wrote: > 2017-10-16 18:14 GMT+02:00 Ben Hoyt : > > Got it -- fair enough. > > > > We deploy so often where I work (a couple of times a week at least) that > 104 > > days seems

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

2017-10-16 18:28 GMT+02:00 Antoine Pitrou : >> What do you think? > > It sounds fine to me! Ok fine, I updated the PEP. Let's start simple with the few functions (5 "clock" functions) which are "obviously" impacted by the precission loss. Victor

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

2017-10-16 18:14 GMT+02:00 Ben Hoyt : > Got it -- fair enough. > > We deploy so often where I work (a couple of times a week at least) that 104 > days seems like an eternity. But I can see where for a very stable file > server or something you might well run it that long without

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On Mon, 16 Oct 2017 18:06:06 +0200 Victor Stinner wrote: > 2017-10-16 17:42 GMT+02:00 Antoine Pitrou : > > Restricting this PEP to the time module would be fine with me. > > Maybe I should add a short sentence to keep the question open, but >

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Got it -- fair enough. We deploy so often where I work (a couple of times a week at least) that 104 days seems like an eternity. But I can see where for a very stable file server or something you might well run it that long without deploying. Then again, why are you doing performance tuning on a

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

2017-10-16 17:42 GMT+02:00 Antoine Pitrou : > Restricting this PEP to the time module would be fine with me. Maybe I should add a short sentence to keep the question open, but exclude it from the direct scope of the PEP? For example: "New nanosecond flavor of these functions

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

2017-10-16 17:37 GMT+02:00 Ben Hoyt : > I've read the examples you wrote here, but I'm struggling to see what the > real-life use cases are for this. When would you care about *both* very > long-running servers (104 days+) and nanosecond precision? I'm not saying it > could

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On Mon, Oct 16, 2017 at 8:37 AM, Ben Hoyt wrote: > I've read the examples you wrote here, but I'm struggling to see what the > real-life use cases are for this. When would you care about *both* very > long-running servers (104 days+) and nanosecond precision? I'm not saying >

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

On Mon, 16 Oct 2017 17:23:15 +0200 Victor Stinner wrote: > 2017-10-16 17:06 GMT+02:00 Antoine Pitrou : > >> This PEP adds five new functions to the ``time`` module: > >> > >> * ``time.clock_gettime_ns(clock_id)`` > >> *

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

I've read the examples you wrote here, but I'm struggling to see what the real-life use cases are for this. When would you care about *both* very long-running servers (104 days+) and nanosecond precision? I'm not saying it could never happen, but would want to see real "experience reports" of when

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

2017-10-16 17:06 GMT+02:00 Antoine Pitrou : >> This PEP adds five new functions to the ``time`` module: >> >> * ``time.clock_gettime_ns(clock_id)`` >> * ``time.clock_settime_ns(clock_id, time: int)`` >> * ``time.perf_counter_ns()`` >> * ``time.monotonic_ns()`` >> *

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Hi, On Mon, 16 Oct 2017 12:42:30 +0200 Victor Stinner wrote: > > ``time.time()`` returns seconds elapsed since the UNIX epoch: January > 1st, 1970. This function loses precision since May 1970 (47 years ago):: This is a funny sentence. I doubt computers (Unix or

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

I read again the discussions on python-ideas and noticed that I forgot to mention the "time_ns module" idea. I also added a section to give concrete examples of the precision loss. https://github.com/python/peps/commit/a4828def403913dbae7452b4f9b9d62a0c83a278 Issues caused by precision loss

[Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Hi, While discussions on this PEP are not over on python-ideas, I proposed this PEP directly on python-dev since I consider that my PEP already summarizes current and past proposed alternatives. python-ideas threads: * Add time.time_ns(): system clock with nanosecond resolution * Why not