>> - time.monotonic(): monotonic clock, its speed may or may not be
>> adjusted by NTP but it only goes forward, may raise an OSError
>> - time.steady(): monotonic clock or the realtime clock, depending on
>> what is available on the platform (use monotonic in priority). may be
>> adjusted by NTP o
>> Oh, I was not aware of this issue. Do you suggest to not use
>> QueryPerformanceCounter() on Windows to implement a monotonic clock?
>
>
> I do not have an opinion on the best way to implement monotonic to guarantee
> that it actually is monotonic.
I opened an issue:
http://bugs.python.org/issu
Cool, Python 3.3 is *much* faster to decode pure ASCII :-)
> encoding string 2.7 3.2 3.3
>
> ascii " " * 1000 5.4 5.3 1.2
4.5 faster than Python 2 here.
> utf-8 " " * 1000 6.7 2.4 2.1
3.2x faster
It's cool because in practice, a lot
> The 80x is a ballpark figure for the maximum expected speedup for
> standard numerical floating point applications.
Ok, but it's just surprising when you read the What's New document.
72x and 80x look to be inconsistent.
> For huge numbers _decimal is also faster than int:
>
> factorial(100
> So using one kind of clock and then "falling back" to the other kind
> is a choice that should be rare, explicit, and discouraged. The
> provision of such a function in the standard library is an attractive
> nuisance -- a thing that people naturally think that they want when
> they haven't thoug
Hi,
I started to write the PEP 418 to clarify the notions of monotonic and
steady clocks.
The PEP is a draft and everyone is invited to contribute!
http://www.python.org/dev/peps/pep-0418/
http://hg.python.org/peps/file/tip/pep-0418.txt
Victor
___
Pyt
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.
>
> The PEP is a draft and everyone is invited to contribute!
time.steady() doesn't fit the benchmarking use case: it looks like we
have to decide between stability and clock resolution.
QueryPerformanceCoun
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.
I replaced time.steady() by time.try_monotonic(). I misunderstood "may
not" in the C++ doc: I understood it as "it may be adjusted by NTP",
whereas it means "it cannot be adjusted". Sorry for the confusion.
> What is the utility of "strict=True"? If I wanted that mode of
> operation, then why would I not just try to use "time.monotonic()"
> directly?
I mentioned the strict=True API in the PEP just to list all
propositions, but the PEP only proposes time.monotonic() and
time.try_monotonic(), no the fl
> steady_clock:
>
> mac = mach_absolute_time
> posix = clock_gettime(CLOCK_MONOTONIC)
> win = QueryPerformanceCounter
I read that QueryPerformanceCounter is no so monotonic, and
GetTickCount is preferred. Is it true?
> high_resolution_clock:
>
> * = { steady_clock, if available
> syste
2012/3/27 Jeffrey Yasskin :
> FWIW, I'm not sure you're the right person to drive time PEPs.
I don't want to drive the PEP. Anyone is invited to contribute, as I
wrote in my first message.
I'm completing/rewriting the PEP with all comments.
Victor
___
> The clock does jump forward when the system suspends. At least some
> existing implementations of steady_clock in C++ already have this problem,
> and I think they all might.
>
> Time with respect to power management state changes is something that the
> PEP should address fully, for each p
> That's simple clear and explicit: try_monotic() tries to use the
> monotic clock if it can, but falls back to time.time() rather than
> failing entirely if no monotonic clock is available.
I renamed time.steady() to time.try_monotonic() in the PEP. It's a
temporary name until we decide what to d
On 27/03/2012 20:18, Matt Joiner wrote:
Also monotonic should either not exist if it's not available, or always
guarantee a (artificially) monotonic value.
What do you mean by "(artificially) monotonic value"? Should Python
workaround OS bugs by always returning the maximum value of the clock?
2012/3/27 guido.van.rossum :
> http://hg.python.org/peps/rev/b9f43fe69691
> changeset: 4152:b9f43fe69691
> user: Guido van Rossum
> date: Mon Mar 26 20:35:14 2012 -0700
> summary:
> Approve PEP 411.
> (...)
> -Status: Draft
> +Status: Approved
The pep0 module doesn't accept the "
Scott wrote:
<< The Boost implementation can be summarized as:
system_clock:
mac = gettimeofday
posix = clock_gettime(CLOCK_REALTIME)
win = GetSystemTimeAsFileTime
steady_clock:
mac = mach_absolute_time
posix = clock_gettime(CLOCK_MONOTONIC)
win = QueryPerformanceCounter
high_resolutio
>> * time.time() = system clock
>> * time.monotonic() = monotonic clock
>> * time.hires() = monotonic clock or fallback to system clock
>>
>> time.hires() definition is exactly what I was trying to implement with
>> "time.steady(strict=True)" / "time.try_monotonic()".
>
> Please don't call the f
>> Scott> monotonic_clock = always goes forward but can be adjusted
>> Scott> steady_clock = always goes forward and cannot be adjusted
>>
>> I don't know if the monotonic clock should be called time.monotonic() or
>> time.steady(). The clock speed can be adjusted by NTP, at least on Linux
>> < 2.6
Hi,
bugs.python.org is down so I'm reporting the bug here :-)
We have a crash in our product when tracing is enabled by
sys.settrace() and threading.settrace(). If a Python generator is
created in a C thread, calling the generator later in another thread
may crash if Python tracing is enabled.
>>> In that case, I don't think time.try_monotonic() is really needed
>>> because we can emulate "time.monotonic()" in software if the platform is
>>> deficient.
>>
>> As I wrote, I don't think that Python should workaround OS bugs. If
>> the OS monotonic clock is not monotonic, the OS should be fi
2012/3/28 Guido van Rossum :
> Interesting bug. :-(
>
> It seems bugs.python.org is back up, so can you file it there too?
It took us weeks to track the bug. Here is the issue:
http://bugs.python.org/issue14432
Victor
___
Python-Dev mailing list
Python-
> I would love to have only one new clock function in 3.3.
I already added time.clock_gettime() to 3.3 :-)
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
> Does this primarily give a high resolution clock, or primarily a
> monotonic clock? That's not clear from either the name, or the PEP.
I expect a better resolution from time.monotonic() than time.time(). I
don't have exact numbers right now, but I began to document each OS
clock in the PEP.
Vic
> I think the PEP should enumerate what platforms that CPython supports
> that will not benefit from a real monotonic clock. I think the number of
> platforms will be such a minority that the emulation makes sense.
> Practicality beats purity, and all.
The PEP lists OS monotonic clocks by platform
> Where in the stdlib do we actually calculate timeouts instead of using
> the timeouts built into the OS (e.g. select())?
At least in threading and queue modules. The common use case is to
retry a function with a timeout if the syscall was interrupted by a
signal (EINTR error). The socket module
> Could you (with help from others who contributed) try to compile a table
> showing, for each platform (Windows/Mac/Linux/BSD) which clocks (or
> variations) we are considering, and for each of those:
>
> - a link for the reference documentation
> - what their typical accuracy is (barring jumps)
>
On 29/03/2012 21:35, Tim Lesher wrote:
From a theoretical standpoint, I can't quite decide what the real error is:
1) the fact that PyGILState_Release() destroys a temporary thread
state that may still be referenced by some objects, or
2) the fact that some code is trying to keep frame objects
>> diff --git a/pep-0418.txt b/pep-0418.txt
>> --- a/pep-0418.txt
>> +++ b/pep-0418.txt
>> @@ -190,13 +190,13 @@
>> Name Resolution Adjusted by NTP? Action on
>> suspend
>> = ===
>> =
>
> Is it
Hi,
Windows provides two main monotonic clocks: QueryPerformanceCounter()
and GetTickCount(). QueryPerformanceCounter() has a good accuracy (0.3
ns - 5 ns) but has various issues and is know to not have a steady
rate. GetTickCount() has a worse accuracy (1 ms - 15 ms) but is more
stable and behave
> Can you go into more detail about QPC()'s issues?
Yes, see the PEP:
http://www.python.org/dev/peps/pep-0418/#windows-queryperformancecounter
> What is unsteady about its rate?
Hum, I read that you can expect a drift between QPC and GetTickCount.
I don't have exact numbers. There are also issue
> No, not really. Anyways, I guess I'll have to further dig down why is
> PEP-416 is really important to Python and why it was likewise rejected,
> supposing I confused the pep 416 and issue 14417 along the way.. :-)
The frozendict builtin type was rejected, but we are going to add
types.MappingPr
2012/3/31 Guido van Rossum :
> Given the amount of disagreement I sense, I think we'll need to wait
> for more people to chime in.
I hope that the PEP now gives enough data to help to choose the best API.
>> Hum, I read that you can expect a drift between QPC and GetTickCount.
>> I don't have exa
> There seem to be a few competing features for clocks that people want:
>
> - monotonic - never going backward at all
> - high resolution
These features look to be exclusive on Windows. On other platforms, it
looks like monotonic clocks are always the most accurate clocks. So I
don't think that
>> Impact: A timeout may be 42 seconds shorter than the requested
>> duration if is uses QPC. For a scheduler, a task would be scheduled at
>> the right moment.
>
> I don't understand this paragraph. And why is it always exactly a loss
> of 42 seconds?
Sorry, it's late here, I'm too tired. A jump
> (...)
> By contrast, stepping only happens if your local clock is just set
> incorrectly and the re-sync delta has more to do with administrative error
> or failed batteries than differences in timekeeping accuracy.
Are you talking about CLOCK_REALTIME or CLOCK_MONOTONIC?
Victor
__
> FYI, Victor, the PEP is slightly incomplete.
Sure. What should be added to the PEP?
> But there's another problem: the TSC frequency actually *does*
> change when SpeedStep kicks in. I know someone who complained bitterly
> about running Half-Life 2 on their shiny new laptop, and when it'd ove
> If we provide a way to check if the monotonic clock is monotonic (or
> not), I agree to drop the flag from time.monotonic(fallback=True) and
> always fallback. I was never a fan of the "truly monotonic clock".
>
> time.clock_info('monotonic')['is_monotonic'] is a good candidate to
> store this in
> I've just finished sketching out a skeleton here:
>
> https://bitbucket.org/cameron_simpson/css/src/fb476fcdcfce/lib/python/cs/clockutils.py
get_clock() returns None if no clock has the requested flags, whereas
I expected an exception (LookupError or NotImplementError?).
get_clock() doesn't re
Hi,
I would to rename time.monotonic() to time.steady() in the PEP 418 for
the following reasons:
- time.steady() may fallback to the system clock which is not
monotonic, it's strange to have to check for
time.get_clock_info('monotonic')['is_monotonic']
- time.steady() uses GetTickCount() inste
>> You seem to have missed the episode where I explained that caching the last
>> value in order to avoid going backwards doesn't work -- at least not if the
>> cached value is internal to the API implementation.
>>
> Yes, and I can't find it by briefly searching my mail. I haven't had the
> ener
> Wait, what?
> I already thought we, several days ago, decided that "steady" was a
> *terrible* name, and that monotonic should *not* fall back to the
> system clock.
Copy of a more recent Guido's email:
http://mail.python.org/pipermail/python-dev/2012-March/118322.html
"Anyway, the more I think
> | get_clock() returns None if no clock has the requested flags, whereas
> | I expected an exception (LookupError or NotImplementError?).
>
> That is deliberate. People can easily write fallback like this:
>
> clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC)
Why not passing a a l
> Lennart Regebro wrote:
>> Well, get_clock(monotonic=True, highres=True) would be a vast
>> improvement over get_clock(MONOTONIC|HIRES).
I don't like this keyword API because you have to use a magically
marker (True). Why True? What happens if I call
get_clock(monotonic=False) or get_clock(monoto
Le 04/04/2012 02:33, Steven D'Aprano a écrit :
Judging by the hundreds of emails regarding PEP 418, the disagreements
about APIs, namings, and even what characteristics clocks should have, I
believe that the suggestion is too divisive (and confusing!) to be
accepted or rejected at this time.
Oh
2012/4/4 Antoine Pitrou :
> On Wed, 4 Apr 2012 02:02:12 +0200
> Victor Stinner wrote:
>> > Lennart Regebro wrote:
>> >> Well, get_clock(monotonic=True, highres=True) would be a vast
>> >> improvement over get_clock(MONOTONIC|HIRES).
>>
>> I do
>> Why does it already have these things when the PEP is not accepted?
>> ...
>> (This is not a rhetorical question, perhaps there is a good reason why
>> these have been added independently of the PEP.)
time.clock_gettime() & friends were added by the issue #10278. The
function was added before s
> I failed to propose a consistent and clear API because I (and Guido!) wanted
> to fallback to the system clock. Falling back to the system clock is a
> problem when you have to define the function in the documentation or if you
> don't want to use the system clock (but do something else) if no mo
2012/4/4 Lennart Regebro :
> On Wed, Apr 4, 2012 at 13:04, Victor Stinner wrote:
>> It depends if the option supports other values. But as I understood,
>> the keyword value must always be True.
>
> Or False, obviously. Which would also be default.
Ok for the default, bu
> I failed to propose a consistent and clear API because I (and Guido!) wanted
> to fallback to the system clock. Falling back to the system clock is a
> problem when you have to define the function in the documentation or if you
> don't want to use the system clock (but do something else) if no mo
>>> Since the only monotonic clock that can be adjusted by NTP is Linux'
>>> CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
>>> give a clock that isn't adjusted by NTP.
>>
>> I thought we decided that NTP adjustment isn't an issue, because
>> it's always gradual.
>
> Well, in t
2012/4/5 PJ Eby :
>> More details why it's hard to define such function and why I dropped
>> it from the PEP.
>>
>> If someone wants to propose again such function ("monotonic or
>> fallback to system" clock), two issues should be solved:
>>
>> - name of the function
>> - description of the funct
>> > For timeout purposes in a single process, such a clock is useful. It just
>> > isn't suitable for benchmarks, or for interprocess coordination.
>>
>> I think it would be better if the proposed algorithm (or whatever
>> algorithm to "fix" timeouts) was implemented by the
>> application/library
Le 06/04/2012 00:17, Cameron Simpson a écrit :
This is where the bitmap approach can be less confusing - the docstring
says "The returned clock shall have all the requested flags". It is at
least very predictable.
By the way, I removed ("deferred") the time.highres() function from the
PEP, and
> 2. Those who think that "monotonic clock" means a clock that never
> jumps, and that runs at a rate approximating the rate of real time.
> This is a very useful kind of clock to have! It is what C++ now calls
> a "steady clock". It is what all the major operating systems provide.
Python cannot g
> 1. The "steadiest" clock on the system. Ideally this would be a steady
> clock, but may not be.
time.monotonic() as proposed in the PEP 418 *is* the steadiest
available clock, but we cannot say that it is steady :-)
> 2. The "most precise" clock on the system. This would have the finest-grain
>
> | This is the original reason for the original defect (issue 10278)
> | unix' clock() doesn't actually provide a clock in this sense, it provides a
> resource usage metric.
>
> Yeah:-( Its help says "Return the CPU time or real time since [...]".
> Two very different things, as demonstrated. I s
> 2. Those who think that "monotonic clock" means a clock that never
> jumps, and that runs at a rate approximating the rate of real time.
> This is a very useful kind of clock to have! It is what C++ now calls
> a "steady clock". It is what all the major operating systems provide.
For the "C++" p
2012/4/7 Janzert :
> On 4/5/2012 6:32 AM, Victor Stinner wrote:
>> I prefer to use CLOCK_MONOTONIC, not because it is also available for
>> older Linux kernels, but because it is more reliable. Even if the
>> underlying clock source is unstable (unstable frequency), a delta o
2012/4/7 Steven D'Aprano :
> Victor Stinner wrote:
>>
>> 2012/4/7 Janzert :
>>>
>>> On 4/5/2012 6:32 AM, Victor Stinner wrote:
>>>>
>>>> I prefer to use CLOCK_MONOTONIC, not because it is also available for
>>>> older L
> IOW "What's good enough for sleep() is good enough for
> user-implemented timeouts and scheduling." as a way to reach at least
> one decision for a platform with agreed-upon cross-platform
> characteristics that are useful.
sleep() is implemented in the kernel. The kernel is notified when a
cloc
2012/4/9 Guido van Rossum :
>>You may need two clocks
>> for this:
>> * time.perf_counter(): high-resolution timer for benchmarking, count
>> time elasped during a sleep
>> * time.process_time(): High-resolution (?) per-process timer from the
>> CPU. (other possible names: time.process_cpu_time()
> | * time.process_time(): High-resolution (?) per-process timer from the
> | CPU. (other possible names: time.process_cpu_time() or
> | time.cpu_time())
>
> POSIX offers CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID that
> seem to suit this need, depending on your threading situation (and
>> sleep() is implemented in the kernel. The kernel is notified when a
>> clock is set, and so can choose how to handle time adjustement. Most
>> "sleeping" functions use the system clock but don't care of clock
>> adjustement.
>
> We're going around in circles. I'm not asking what sleep does, I wa
>> We're going around in circles. I'm not asking what sleep does, I want
>> on principle a timer that does the same thing as sleep(), regardless
>> of how sleep() works. So if on some OS sleep() uses the same algorithm
>> as CLOCK_MONOTONIC_RAW, I want my timer to use that too. But if on
>> some ot
>> In any case, NTP is not the only thing that adjusts the clock, e.g. the
>> operating system will adjust the time for daylight savings.
>
> Daylight savings time is not a clock adjustment, at least not in the sense
> this thread has mostly been talking about the word "clock". It doesn't
> affect
2012/4/11 Jim Jewett :
> I believe PEP 418 (or at least the discussion) would benefit greatly
> from a glossary to encourage people to use the same definitions. This
> is arguably the Definitions section, but it should move either near
> the end or (preferably) ahead of the Functions. It also nee
> The descriptions should really stress the scope of the result's
> validity. My guess (or wish :-)) would be:
>
> - time.monotonic(): system-wide results, comparable from one process to
> another
> - time.perf_counter(): process-wide results, comparable from one thread
> to another (?)
> - time.
By the way, I hesitate to add a new mandatory key to
time.get_clock_info() which indicates if the clock includes time
elapsed during a sleep. Is "is_realtime" a good name for such flag?
Examples:
time.get_clock_info('time')['is_realtime'] == True
time.get_clock_info('monotonic')['is_realtime'] ==
Hi,
Before posting a first draft of the PEP 418 to python-dev, I have some
questions.
== Naming: time.monotonic() or time.steady()? ==
I like the "steady" name but different people complained that the
steady name should not be used if the function falls back to the
system clock or if the clock i
>> I prefer "steady" over "monotonic" because the steady property is what
>> users really expect from a "monotonic" clock. A monotonic but not
>> steady clock may be useless.
>
> "steady" is ambiguous IMO. It can only be "steady" in reference to
> another clock - but which one ? (real time presumab
> Here is a simplified version of the first draft of the PEP 418. The
> full version can be read online.
> http://www.python.org/dev/peps/pep-0418/
FYI there is no time.thread_time() function. It would only be
available on Windows and Linux. It does not use seconds but CPU
cycles. No module or pro
2012/4/15 M.-A. Lemburg :
> I'd suggest to also include a tool or API to determine the
> real resolution of a time function (as opposed to the advertised
> one). See pybench's clockres.py helper as example.
The PEP includes such tool, but I forgot to mention it in the PEP:
http://hg.python.org/pep
Hi,
The frozendict (PEP 416) was rejected, but I just added the
types.MappingProxyType. This type is not new, it existed since Python
2.2 as the internal dict_proxy type. See also the issue #14386.
I would like to know if I can edit the rejected PEP, or if Guido
prefers to do it, to mention the n
> time.perf_counter()
> ^^^
>
> Performance counter with the highest available precision to measure a
> duration. It does include time elapsed during sleep and is
> system-wide. The reference point of the returned value is undefined,
> so that only the difference between the resul
2012/4/16 Matt Joiner :
> This is becoming the Manhattan Project of bike sheds.
FreeBSD FAQ contains an entry "Why should I care what color the
bikeshed is?" which mention a "sleep(1) should take fractional second
arguments" saga in 1999.
http://www.freebsd.org/doc/en/books/faq/misc.html#BIKESHED
> Here is a simplified version of the first draft of the PEP 418. The
> full version can be read online.
> http://www.python.org/dev/peps/pep-0418/
I wrote an implementation in pure Python using ctypes for Python < 3.3:
https://bitbucket.org/haypo/misc/src/tip/python/pep418.py
I tested it on Lin
> I think what the user cares about is "what is the smallest tick that
> this clock result will faithfully represent?". If the number of bits
> returned is larger than the clock accuracy, you want the clock accuracy.
> If the number of bits returned is smaller than the clock accuracy,
> you want t
> Here is a simplified version of the first draft of the PEP 418. The
> full version can be read online.
> http://www.python.org/dev/peps/pep-0418/
>
> The implementation of the PEP can be found in this issue:
> http://bugs.python.org/issue14428
The PEP is now fully ready: I just finished the impl
>> Ok ok, resolution / accuracy / precision are confusing (or at least
>> not well known concepts).
>
> Maybe not to us, but in fields like astronomy and mechanical
> engineering there are commonly accepted definitions:
I was just talking of the name of the time.perf_counter() function:
"perf_coun
>> If anyone is motivated to write a perfect (or at least better) glossary,
>> please do it!
>
> We don't want a perfect glossary, we want one we agree on, that
> defines terms consistently with the way they're used in the PEP.
> However, what I read in this thread is that the PEP protagonist
> do
> That was nice of you. In return, I'll go over the PEP to check that
> usage is appropriate (eg, in some places "resolution" was used in the
> sense of computer science's "precision" == reported digits).
Oh, this is very likely :-)
> BTW, this not a criticism, you did a great job of putting all
> PEP: 419
> Title: Protecting cleanup statements from interruptions
> Version: $Revision$
> Last-Modified: $Date$
> Author: Paul Colomiets
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 06-Apr-2012
> Python-Version: 3.3
Hi, I think your PEP should at least mention
2012/4/15 Victor Stinner :
>> Here is a simplified version of the first draft of the PEP 418. The
>> full version can be read online.
>> http://www.python.org/dev/peps/pep-0418/
>
> FYI there is no time.thread_time() function. It would only be
> available on Windows
>> Well, I asked on IRC what I should do for these definitions because
>> I'm too tired to decide what to do. [[...]] I replaced these definitions
>> with yours.
>
> That was nice of you. In return, I'll go over the PEP to check that
> usage is appropriate (eg, in some places "resolution" was use
> Here is a simplified version of the first draft of the PEP 418. The
> full version can be read online.
> http://www.python.org/dev/peps/pep-0418/
Thanks to everyone who helped me to work on this PEP!
I integrated last comments. There is no more open question. (Or did I
miss something?)
I didn'
> Monotonic
> -
>
> This is a particularly tricky term, as there are several subtly
> incompatible definitions in use.
Is it a definition for the glossary?
> C++ followed the mathematical
> definition, so that a monotonic clock only promises not to go
> backwards.
The "C++ Timeout Speci
> Precision
> -
>
> This is another tricky term,
This is a good reason why it is no more used in the PEP :-)
> Note that "precision" as reported by the clock itself may use yet
> another definition, and may differ between clocks.
Some C function provides the frequency of the clock (and s
>> I don't know any monotonic with a defined epoch or
>> mappable to the civil time.
>
> The very basic "seconds (not even milliseconds) since the beginning of
> 1970" fits that definition, but doesn't seem to fit what most people
> mean by "Monotonic Clock".
>
> I'm still a little fuzzy on *why* i
2012/4/24 jesus.cea :
> http://hg.python.org/cpython/rev/2023f48b32b6
> changeset: 76537:2023f48b32b6
> user: Jesus Cea
> date: Tue Apr 24 20:59:17 2012 +0200
> summary:
> Closes Issue #14661: posix module: add O_EXEC, O_SEARCH, O_TTY_INIT (I add
> some Solaris constants too)
Do
2012/4/24 Edward C. Jones :
> CPython 3.3.0a2 (default, Apr 24 2012, 10:47:03) [GCC 4.4.5]
> Linux-2.6.32-5-amd64-x86_64-with-debian-6.0.4 little-endian
>
> Ran "make test". Hung during test_socket. Used CNTL-C to exit the test.
Can you investigate what is blocked in the test? Can you at least
p
> 1) time.clock is deprecated, but also supported by get_clock_info. Why
> bother supporting it if you don't want people to use it?
It will not be removed before Python 4, the function is still used by
Python < 3.3.
> 2) get_clock_info returns a dict. Why not a namedtuple?
I don't like the tuple
> Surely those are all very minor quibbles. I have one myself: at some
> point it says:
>
> On Linux, it is possible to use
> time.clock_gettime(CLOCK_THREAD_CPUTIME_ID).
>
> But the PEP doesn't define a function by that name. Is it an editing
> glitch? (Some of the pseudo code also uses this.)
> 3) The dict returned by get_clock_info includes an optional key,
> "is_adjusted". Why is it optional?
More complete answer.
Rules used to fill the is_adjusted flag:
- System clock: is_adjusted=1 because the clock can be set manually
by the system administrator, except on Windows: is_adjusted
>> As a thin wrapper, adding it to the time module was pretty much
>> uncontroversial, I think. The PEP proposes cross-platform
>> functions with consistent semantics, which is where a discussion was
>> needed.
>
> True, but does this mean clock_gettime and friends only exist on
> POSIX? Shouldn't
>>> 2) get_clock_info returns a dict. Why not a namedtuple?
>>
>> Future flexibility. And there's no need for it to be a *tuple*.
>
> I haven't been paying attention to this discussion, so this isn't a
> comment on any time functions specifically.
>
> But we generally use a namedtuple (or structseq
Hi Guido,
2012/4/28 Guido van Rossum :
> I read most of the PEP and I think it is ready for acceptance! Thanks
> for your patience in shepherding this through such a difficult and
> long discussion.
You're welcome, but many developers helped me!
> Also thanks to the many other contributors,
> es
>> diff --git a/Lib/timeit.py b/Lib/timeit.py
>> --- a/Lib/timeit.py
>> +++ b/Lib/timeit.py
>> @@ -15,8 +15,8 @@
>> -n/--number N: how many times to execute 'statement' (default: see below)
>> -r/--repeat N: how many times to repeat the timer (default 3)
>> -s/--setup S: statement to be ex
>> + if (start >= length || end < start) {
>> + assert(end == length);
>> + return PyUnicode_New(0, 0);
>> + }
>
> That assert doesn't look right.
Oh, you're right. I added it for the first case: start>=length. But
the assertion is really useless, I removed it. Thanks!
Victor
>> http://hg.python.org/cpython/rev/f1db931b93d3
>> changeset: 76730:f1db931b93d3
>> user: Victor Stinner
>> date: Thu May 03 13:10:40 2012 +0200
>> summary:
>> Issue #14687: str%tuple now uses an optimistic "unicode writer" i
>> Py_LOCAL_INLINE(void)
>
> Do these have to be marked inline?
Functions used in loops, yes: the inline keyword *does* impact
performances (5% slower). I removed the keyword for the other
unicode_writer methods.
Victor
___
Python-Dev mailing list
Pyth
3001 - 3100 of 3215 matches
Mail list logo
