Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Dev

Drop the new time.wallclock() function?

 

 

First page Previous page 1 2 3 Next page Last page  View All Python dev RSS feed   Index | Next | Previous | View Threaded


steve at pearwood

Mar 15, 2012, 4:18 PM

Post #51 of 67 (994 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

Terry Reedy wrote:
> On 3/15/2012 5:27 PM, Alexander Belopolsky wrote:
>> On Thu, Mar 15, 2012 at 3:55 PM, Matt Joiner<anacrolix [at] gmail> wrote:
>>> +1. I now prefer time.monotonic(), no flags.
>>
>> Am I alone thinking that an adjective is an odd choice for a function
>> name?
>
> I would normally agree, but in this case, it is a function of a module
> whose short name names what the adjective is modifying. I expect that
> this will normally be called with the module name.
>
>> I think monotonic_clock or monotonic_time would be a better option.
>
> time.monotonic_time seems redundant.

Agreed. Same applies to "steady_time", and "steady" on its own is weird.
Steady what?

While we're bike-shedding, I'll toss in another alternative. Early Apple
Macintoshes had a system function that returned the time since last reboot
measured in 1/60th of a second, called "the ticks".

If I have understood correctly, the monotonic timer will have similar
properties: guaranteed monotonic, as accurate as the hardware can provide, but
not directly translatable to real (wall-clock) time. (Wall clocks sometimes go
backwards.)

The two functions are not quite identical: Mac "ticks" were 32-bit integers,
not floating point numbers. But the use-cases seem to be the same.

time.ticks() seems right as a name to me. It suggests a steady heartbeat
ticking along, without making any suggestion that it returns "the time".



--
Steven

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


anacrolix at gmail

Mar 15, 2012, 5:50 PM

Post #52 of 67 (995 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

Windows also has this albeit course grained and also 32 bit. I don't think
ticks reflects the reason why using the timer is desirable.

monotonic_time seems reasonable, there's no reason to persist short names
when users can import it how they like.
On Mar 16, 2012 7:20 AM, "Steven D&apos;Aprano" <steve [at] pearwood> wrote:

> Terry Reedy wrote:
>
>> On 3/15/2012 5:27 PM, Alexander Belopolsky wrote:
>>
>>> On Thu, Mar 15, 2012 at 3:55 PM, Matt Joiner<anacrolix [at] gmail>
>>> wrote:
>>>
>>>> +1. I now prefer time.monotonic(), no flags.
>>>>
>>>
>>> Am I alone thinking that an adjective is an odd choice for a function
>>> name?
>>>
>>
>> I would normally agree, but in this case, it is a function of a module
>> whose short name names what the adjective is modifying. I expect that this
>> will normally be called with the module name.
>>
>> I think monotonic_clock or monotonic_time would be a better option.
>>>
>>
>> time.monotonic_time seems redundant.
>>
>
> Agreed. Same applies to "steady_time", and "steady" on its own is weird.
> Steady what?
>
> While we're bike-shedding, I'll toss in another alternative. Early Apple
> Macintoshes had a system function that returned the time since last reboot
> measured in 1/60th of a second, called "the ticks".
>
> If I have understood correctly, the monotonic timer will have similar
> properties: guaranteed monotonic, as accurate as the hardware can provide,
> but not directly translatable to real (wall-clock) time. (Wall clocks
> sometimes go backwards.)
>
> The two functions are not quite identical: Mac "ticks" were 32-bit
> integers, not floating point numbers. But the use-cases seem to be the same.
>
> time.ticks() seems right as a name to me. It suggests a steady heartbeat
> ticking along, without making any suggestion that it returns "the time".
>
>
>
> --
> Steven
>
> ______________________________**_________________
> Python-Dev mailing list
> Python-Dev [at] python
> http://mail.python.org/**mailman/listinfo/python-dev<http://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> anacrolix%40gmail.com<http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com>
>


kristjan at ccpgames

Mar 19, 2012, 2:07 AM

Post #53 of 67 (964 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

Do you really want to add an obscure Boolean flag to the function just so that python can warn you that perhaps your platform is so old and so weird that Python can't guarantee that the performance measurements are to a certain _undefined_ quality?

Please note, that the function makes no claims to the resolution or precision of the timer involved. Only that it moves only forward. It is therefore completely and utterly redundant to add a "strict" value, because we would only be behave "strictly" according to an _undefined specification_.

K

-----Original Message-----
From: python-dev-bounces+kristjan=ccpgames.com [at] python [mailto:python-dev-bounces+kristjan=ccpgames.com [at] python] On Behalf Of Lennart Regebro
Sent: 15. mars 2012 04:44
To: Matt Joiner
Cc: Python Dev
Subject: Re: [Python-Dev] Drop the new time.wallclock() function?

On Thu, Mar 15, 2012 at 02:58, Matt Joiner <anacrolix [at] gmail> wrote:
> Victor, I think that steady can always be monotonic, there are time
> sources enough to ensure this on the platforms I am aware of. Strict
> in this sense refers to not being adjusted forward, i.e.
> CLOCK_MONOTONIC vs CLOCK_MONOTONIC_RAW.
>
> Non monotonicity of this call should be considered a bug. Strict would
> be used for profiling where forward leaps would disqualify the timing.

This makes sense to me.

//Lennart
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com


_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


zooko at zooko

Mar 23, 2012, 9:55 AM

Post #54 of 67 (981 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

> I merged the two functions into one function: time.steady(strict=False).
>
> time.steady() should be monotonic most of the time, but may use a fallback.
>
> time.steady(strict=True) fails with OSError or NotImplementedError if
> reading the monotonic clock failed or if no monotonic clock is available.

If someone wants time.steady(strict=False), then why don't they just
continue to use time.time()?

I want time.steady(strict=True), and I'm glad you're providing it and
I'm willing to use it this way, although it is slightly annoying
because "time.steady(strict=True)" really means
"time.steady(i_really_mean_it=True)". Else, I would have used
"time.time()".

I am aware of a large number of use cases for a steady clock (event
scheduling, profiling, timeouts), and a large number of uses cases for
a "NTP-respecting wall clock" clock (calendaring, displaying to a
user, timestamping). I'm not aware of any use case for "steady if
implemented, else wall-clock", and it sounds like a mistake to me.

Regards,

Zooko
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Mar 23, 2012, 10:27 AM

Post #55 of 67 (964 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

> I want time.steady(strict=True), and I'm glad you're providing it and
> I'm willing to use it this way, although it is slightly annoying
> because "time.steady(strict=True)" really means
> "time.steady(i_really_mean_it=True)". Else, I would have used
> "time.time()".
>
> I am aware of a large number of use cases for a steady clock (event
> scheduling, profiling, timeouts), and a large number of uses cases for
> a "NTP-respecting wall clock" clock (calendaring, displaying to a
> user, timestamping). I'm not aware of any use case for "steady if
> implemented, else wall-clock", and it sounds like a mistake to me.

time.steady(strict=False) is what you need to implement timeout.

If you use time.steady(strict=True) for timeout, it means that you
cannot use select, threads, etc. if your platform doesn't provide
monotonic clock, whereas it works "well" (except the issue of adjusted
time) with Python < 3.3.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


glyph at twistedmatrix

Mar 23, 2012, 1:40 PM

Post #56 of 67 (986 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

On Mar 23, 2012, at 12:55 PM, Zooko Wilcox-O'Hearn wrote:

>> I merged the two functions into one function: time.steady(strict=False).
>>
>> time.steady() should be monotonic most of the time, but may use a fallback.
>>
>> time.steady(strict=True) fails with OSError or NotImplementedError if
>> reading the monotonic clock failed or if no monotonic clock is available.
>
> If someone wants time.steady(strict=False), then why don't they just
> continue to use time.time()?
>
> I want time.steady(strict=True), and I'm glad you're providing it and
> I'm willing to use it this way, although it is slightly annoying
> because "time.steady(strict=True)" really means
> "time.steady(i_really_mean_it=True)". Else, I would have used
> "time.time()".
>
> I am aware of a large number of use cases for a steady clock (event
> scheduling, profiling, timeouts), and a large number of uses cases for
> a "NTP-respecting wall clock" clock (calendaring, displaying to a
> user, timestamping). I'm not aware of any use case for "steady if
> implemented, else wall-clock", and it sounds like a mistake to me.

I think I've lost the thread of this discussion. Is that really what "strict=False" was supposed to mean?

I am aware of use-cases which want to respect slew, but reject steps. The local clock might not be all that reliable, and slew actually keeps it closer to "real" time. My understanding was that strict=True was something like CLOCK_MONOTONIC_RAW and strict=False was just CLOCK_MONOTONIC.

I am increasingly thinking that the first order of business here should be to expose the platform-specific mechanisms directly, then try to come up with a unifying abstraction in the time module later. It's hard enough to understand the substantially dense verbiage around all of these different timers on their respective platforms; understanding which one exactly Python is swaddling up in a portability layer seems bound to generate confusion. Not to mention that you run into awesome little edge cases like this: https://github.com/ThomasHabets/monotonic_clock/blob/master/src/monotonic_win32.c#L62 which means sometimes you really really need to know exactly which clock is getting used, if you want to make it work right (unless Python is going to ship with all of these workarounds on day 1).

(I still object to the "time.steady" naming, because this is what people in the make-believe land of C++ call it. The people who live in the real world of C and POSIX all refer to it as "monotonic". And even the C++ purists slip up sometimes, c.f. <http://en.cppreference.com/w/cpp/chrono/steady_clock>: "Class std::chrono::steady_clock represents a monotonic clock.")

If there really are some applications for which the desired behavior is 'monotonic clock, but if you can't get one, nevermind, wallclock is good enough', it strikes me that this should be as explicit as possible, it should not be the default, and if

try:
value = time.steady()
except OhWowYourComputerReallyHasProblems:
value = time.time()

is generally considered too onerous, it should be spelled time.steady(fallback=time.time).

-glyph


p.f.moore at gmail

Mar 23, 2012, 2:11 PM

Post #57 of 67 (982 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

On 23 March 2012 20:40, Glyph <glyph [at] twistedmatrix> wrote:
> I am increasingly thinking that the first order of business here should be
> to expose the platform-specific mechanisms directly, then try to come up
> with a unifying abstraction in the time module later.

+1.

Paul
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


yselivanov.ml at gmail

Mar 23, 2012, 3:54 PM

Post #58 of 67 (995 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

On 2012-03-23, at 4:40 PM, Glyph wrote:
> (I still object to the "time.steady" naming, because this is what people in the make-believe land of C++ call it. The people who live in the real world of C and POSIX all refer to it as "monotonic". And even the C++ purists slip up sometimes, c.f. <http://en.cppreference.com/w/cpp/chrono/steady_clock>: "Class std::chrono::steady_clock represents a monotonic clock.")

+1.

I also think that the function should be called 'monotonic' and simply fail with OSError on platforms that don't support such clocks. The 'strict' argument is non-intuitive.

-
Yury
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


yselivanov.ml at gmail

Mar 23, 2012, 3:56 PM

Post #59 of 67 (999 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

On 2012-03-23, at 1:27 PM, Victor Stinner wrote:

>> I want time.steady(strict=True), and I'm glad you're providing it and
>> I'm willing to use it this way, although it is slightly annoying
>> because "time.steady(strict=True)" really means
>> "time.steady(i_really_mean_it=True)". Else, I would have used
>> "time.time()".
>>
>> I am aware of a large number of use cases for a steady clock (event
>> scheduling, profiling, timeouts), and a large number of uses cases for
>> a "NTP-respecting wall clock" clock (calendaring, displaying to a
>> user, timestamping). I'm not aware of any use case for "steady if
>> implemented, else wall-clock", and it sounds like a mistake to me.
>
> time.steady(strict=False) is what you need to implement timeout.
>
> If you use time.steady(strict=True) for timeout, it means that you
> cannot use select, threads, etc. if your platform doesn't provide
> monotonic clock, whereas it works "well" (except the issue of adjusted
> time) with Python < 3.3.

Why can't I use select & threads? You mean that if a platform does not
support monotonic clocks it also does not support threads and select sys
call?

-
Yury
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


anacrolix at gmail

Mar 23, 2012, 4:06 PM

Post #60 of 67 (954 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

Yes, call it what it is. monotonic or monotonic_time, because that's why
I'm using it. No flags.

I've followed this thread throughout, and I'm still not sure if "steady"
gives the real guarantees it claims. It's trying to be too much. Existing
bugs complain about backward jumps and demand a clock that doesn't do this.
The function should guarantee monotonicity only, and not get
overcomplicated.


victor.stinner at gmail

Mar 23, 2012, 4:07 PM

Post #61 of 67 (968 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

2012/3/23 Yury Selivanov <yselivanov.ml [at] gmail>:
> Why can't I use select & threads?  You mean that if a platform does not
> support monotonic clocks it also does not support threads and select sys
> call?

Python 3.3 now uses time.steady(strict=False) in the threading and
queue modules. If we replace it by time.steady(strict=True), you may
get an error if your platform doesn't provide a monotonic clock and so
you cannot use these modules.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


yselivanov.ml at gmail

Mar 23, 2012, 4:21 PM

Post #62 of 67 (960 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

On 2012-03-23, at 7:07 PM, Victor Stinner wrote:

> 2012/3/23 Yury Selivanov <yselivanov.ml [at] gmail>:
>> Why can't I use select & threads? You mean that if a platform does not
>> support monotonic clocks it also does not support threads and select sys
>> call?
>
> Python 3.3 now uses time.steady(strict=False) in the threading and
> queue modules. If we replace it by time.steady(strict=True), you may
> get an error if your platform doesn't provide a monotonic clock and so
> you cannot use these modules.

Why this won't work?

try:
from time import monotonic as _time
except ImportError:
from time import time as _time

OR (if we decide to fail on first call, instead of ImportError)

import time
try:
time.monotonic()
except OSError:
_time = time
else:
_time = time.monotonic

And then just use '_time' in your code? What's the deal with the
'strict' kwarg?

I really like how it currently works with epoll, for instance. It either
exists in the 'select' module, or not, if the host OS doesn't support it.
I think it should be the same for 'time.monotonic'.

-
Yury

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


zooko at zooko

Mar 26, 2012, 3:31 PM

Post #63 of 67 (1033 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

On Fri, Mar 23, 2012 at 11:27 AM, Victor Stinner
<victor.stinner [at] gmail> wrote:
>
> time.steady(strict=False) is what you need to implement timeout.

No, that doesn't fit my requirements, which are about event
scheduling, profiling, and timeouts. See below for more about my
requirements.

I didn't say this explicitly enough in my previous post:

Some use cases (timeouts, event scheduling, profiling, sensing)
require a steady clock. Others (calendaring, communicating times to
users, generating times for comparison to remote hosts) require a wall
clock.

Now here's the kicker: each use case incur significant risks if it
uses the wrong kind of clock.

If you're implementing event scheduling or sensing and control, and
you accidentally get a wall clock when you thought you had a steady
clock, then your program may go seriously wrong -- events may fire in
the wrong order, measurements of your sensors may be wildly incorrect.
This can lead to serious accidents. On the other hand, if you're
implementing calendaring or display of "real local time of day" to a
user, and you are using a steady clock for some reason, then you risk
displaying incorrect results to the user.

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 though about it very carefully, but that is actually
dangerous.

If someone has a use case which fits the "steady or else fall back to
wall clock" pattern, I would like to learn about it.

Regards,

Zooko
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


glyph at twistedmatrix

Mar 26, 2012, 3:47 PM

Post #64 of 67 (957 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

On Mar 26, 2012, at 6:31 PM, Zooko Wilcox-O'Hearn wrote:

> On Fri, Mar 23, 2012 at 11:27 AM, Victor Stinner
> <victor.stinner [at] gmail> wrote:
>>
>> time.steady(strict=False) is what you need to implement timeout.
>
> No, that doesn't fit my requirements, which are about event
> scheduling, profiling, and timeouts. See below for more about my
> requirements.
>
> I didn't say this explicitly enough in my previous post:
>
> Some use cases (timeouts, event scheduling, profiling, sensing)
> require a steady clock. Others (calendaring, communicating times to
> users, generating times for comparison to remote hosts) require a wall
> clock.
>
> Now here's the kicker: each use case incur significant risks if it
> uses the wrong kind of clock.
>
> If you're implementing event scheduling or sensing and control, and
> you accidentally get a wall clock when you thought you had a steady
> clock, then your program may go seriously wrong -- events may fire in
> the wrong order, measurements of your sensors may be wildly incorrect.
> This can lead to serious accidents. On the other hand, if you're
> implementing calendaring or display of "real local time of day" to a
> user, and you are using a steady clock for some reason, then you risk
> displaying incorrect results to the user.
>
> 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 though about it very carefully, but that is actually
> dangerous.
>
> If someone has a use case which fits the "steady or else fall back to
> wall clock" pattern, I would like to learn about it.

I feel that this should be emphasized. Zooko knows what he's talking about here. Listen to him :). (Antoine has the right idea. I think it's well past time for a PEP on this feature.)

-glyph

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Mar 26, 2012, 4:07 PM

Post #65 of 67 (980 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

> 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 though about it very carefully, but that is actually
> dangerous.
>
> If someone has a use case which fits the "steady or else fall back to
> wall clock" pattern, I would like to learn about it.

Python 3.2 doesn't provide a monotonic clock, so most program uses
time.time() even if a monotonic clock would be better in some
functions. For these programs, you can replace time.time() by
time.steady() where you need to compute a time delta (e.g. compute a
timeout) to avoid issues with the system clock update. The idea is to
improve the program without refusing to start if no monotonic clock is
available.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


zooko at zooko

Mar 26, 2012, 7:41 PM

Post #66 of 67 (964 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

On Mon, Mar 26, 2012 at 5:07 PM, Victor Stinner
<victor.stinner [at] gmail> wrote:
>>
>> If someone has a use case which fits the "steady or else fall back to wall clock" pattern, I would like to learn about it.
>
> Python 3.2 doesn't provide a monotonic clock, so most program uses time.time() even if a monotonic clock would be better in some functions. For these programs, you can replace time.time() by time.steady() where you need to compute a time delta (e.g. compute a timeout) to avoid issues with the system clock update. The idea is to improve the program without refusing to start if no monotonic clock is available.

I agree that this is a reasonable use case. I think of it as basically
being a kind of backward-compatibility, for situations where an
unsteady clock is okay, and a steady clock isn't available. Twisted
faces a similar issue:

http://twistedmatrix.com/trac/ticket/2424

It might good for use cases like this to explicitly implement the
try-and-fallback, since they might have specific needs about how it is
done. For one thing, some such uses may need to emit a warning, or
even to require the caller to explicitly override, such a refusing to
start if a steady clock isn't available unless the user specifies
"--unsteady-clock-ok".

For motivating examples, consider software written using Twisted >
12.0 or Python > 3.2 which is using a clock to drive real world
sensing and control -- measuring the position of a machine and using
time deltas to calculate the machine's velocity, in order to
automatically control the motion of the machine. For some uses, it is
okay if the measurement could, in rare cases, be drastically wrong.
For other uses, that is not an acceptable risk.

One reason I'm sensitive to this issue is that I work in the field of
security, and making the behavior dependent on the system clock
extends the "reliance set", i.e. the set of things that an attacker
could use against you. For example, if your robot depends on the
system clock for its sensing and control, and if your system clock
obeys NTP, then the set of things that an attacker could use against
you includes your NTP servers. If your robot depends instead on a
steady clock, then NTP servers are not in the reliance set.

Now, if your control platform doesn't have a steady clock, you may
choose to go ahead, while making sure that the NTP servers are
authenticated, or you may choose to disable NTP on the control
platform, etc., but that choice might need to be made explicitly by
the operator, rather than automatically by the library.

Regards,

Zooko
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


anacrolix at gmail

Mar 26, 2012, 7:55 PM

Post #67 of 67 (945 views)
Permalink
Re: Drop the new time.wallclock() function? [In reply to]

Inside time.steady, there are two different clocks trying to get out.

I think this steady business should be removed sooner rather than later.

First page Previous page 1 2 3 Next page Last page  View All Python dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.