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 identifiers to the time module
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 1
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 lis
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
https
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
__
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 case UDP latencies o
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
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 mostly designed for ha
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
> > revelant point. Even if system clocks are synchronized on a single
> > computer, I read that you
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 a NTP
> synchronization eve
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 synchronize
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 time., datetim
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 ?!
>
> - https://schol
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) whatever unit you want:
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 issue, open since a long ti
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 clock speeds,
> but
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 scaling
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
>> fundamental changes in the nature of computing ha
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 relativistic effects, the
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" > > 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 fu
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 proposed
> this PEP directly on
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
> to reduce the number of functions (the 'pico'
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 the future, I predict t
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 understand
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 time.process_time_ns():
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 1
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 rationale
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
> 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
__
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() is needed,
> but not the na
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
functi
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" functions) which are "obviously" impacted by the
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 like an eternity. But I can see where for a v
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
___
Pyt
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 deploying. Then
> a
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
> exclude it from the direct scope of the PEP? For exa
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 "
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 may be added later, i
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 never happen, but would
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
> it could never happe
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)``
> >> * ``time.clock_settime_ns(clock_id, time: int)``
> >> * ``time.perf_counter_ns()
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
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()``
>> * ``time.time_ns()``
>
> Why not ``
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 not) had
nanosecond clocks in
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
-
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 picosec
46 matches
Mail list logo
