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

Mailing List Archive: Python: Dev

an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

 

 

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


cs at zip

Apr 1, 2012, 5:43 PM

Post #1 of 51 (455 views)
Permalink
an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

On 28Mar2012 23:40, Victor Stinner <victor.stinner [at] gmail> wrote:
| > 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.

I wish to raise an alternative to these set-in-stone policy-in-the-library
choices, and an alternative to any proposal that does fallback in a function
whose name suggests otherwise.

Off in another thread on PEP 418 I suggested a cleaner approach to
offering clocks to the user: let the user ask!

My (just two!) posts on this are here:

http://www.mail-archive.com/python-dev [at] python/msg66174.html
http://www.mail-archive.com/python-dev [at] python/msg66179.html

The second post is more important as it fleshes out my reasons for
considering this appraoch better.

I've just finished sketching out a skeleton here:

https://bitbucket.org/cameron_simpson/css/src/fb476fcdcfce/lib/python/cs/clockutils.py

In short:

- take Victor's hard work on system clocks and classifying thm by
feature set

- tabulate access to them in a list of clock objects

- base access class goes (example user call):

# get a clock object - often a singleton under the hood
T = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_STEADY|T_HIRES)
# what kind of clock did I get?
print T.flags
# get the current time
now = T.now

- offer monotonic() and/or steady() etc as convenience functions
calling get_clock() in a fashion like the above example

- don't try to guess the user's use case ahead of time

This removes policy from the library functions and makes it both simple
and obvious in the user's calling code, and also makes it possible for
the user to inspect the clock and find out what quality/flavour of clock
they got.

Please have a glance through the code, especially the top and botth bits;
it is only 89 lines long and includes (presently) just a simple object for
time.time() and (importantly for the bikeshedding) an example synthetic
clock to give a monotonic caching clock from another non-monotonic clock
(default, again, time.time() in this prototype).

Suitably fleshed out with access to the various system clocks, this can
offer all the current bikeshedding in a simple interface and without
constraining user choices to "what we thought of, or what we thought
likely".

Cheers,
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

Availability: Samples Q1/97
Volume H2/97
So, it's vapor right now, but if you want to sell vapor in 1997 you
better had damn fast vapor then...
- Burkhard Neidecker-Lutz on the DEC Alpha 21264, October 1996
_______________________________________________
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

Apr 2, 2012, 4:37 AM

Post #2 of 51 (441 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

> 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 remember if a clock works or not (if it raises an
OSError) and does not fallback to the next clock on error. See
"pseudo-codes" in the PEP 418.

The idea of flags attached to each clock is interesting, but I don't
like the need of different list of clocks. Should I use
MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and
high-resolution clock? It would be simpler to have only one global and
*private* list.

If you have only one list of clocks, how do sort the list to get
QueryPerformanceCounter when the user asks for highres and
GetTickCount when the user asks for monotonic? The "if clock.flags &
flags == flags:" test in get_clock() is maybe not enough. I suppose
that we would have the following flags for Windows functions:

QueryPerformanceCounter.flags = T_HIRES
GetTickCount.flags = T_MONOTONIC | T_STEADY

(or maybe QueryPerformanceCounter.flags = T_HIRES | T_MONOTONIC ?)

monotonic_clock() should maybe try to get a clock using the following
list of conditions:
- T_MONOTONIC | T_STEADY
- T_MONOTONIC | T_HIGHRES
- T_MONOTONIC

The T_HIGHRES flag in unclear, even in the PEP. According to the PEP,
any monotonic clock is considered as a "high-resolution" clock. Do you
agree? So we would have:

GetTickCount.flags = T_MONOTONIC | T_STEADY | T_HIGHRES

Even if GetTickCount has only an accuracy of 15 ms :-/

Can list please give the list of flags of each clocks listed in the
PEP? Only clocks used for time.time, time.monotonic and time.highres
(not process and thread clocks nor QueryUnbiasedInterruptTime).

>      # get a clock object - often a singleton under the hood
>      T = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_STEADY|T_HIRES)
>      # what kind of clock did I get?
>      print T.flags
>      # get the current time
>      now = T.now

The API looks much more complex than the API proposed in PEP 418 just
to get the time. You have to call a function to get a function, and
then call the function, instead of just calling a function directly.

Instead of returning an object with a now() method, I would prefer to
get directly the function getting time, and another function to get
"metadata" of the clock.

> This removes policy from the library functions and makes it both simple
> and obvious in the user's calling code, and also makes it possible for
> the user to inspect the clock and find out what quality/flavour of clock
> they got.

I'm not sure that users understand correctly differences between all
these clocks and are able to use your API correctly. How should I
combinese these 3 flags (T_HIRES, T_MONOTONIC and T_STEADY)? Can I use
any combinaison?

Which flags are "portable"? Or should I always use an explicit
fallback to ensure getting a clock on any platform?

Could you please update your code according to my remarks? I will try
to integrate it into the PEP. A PEP should list all alternatives!

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


cs at zip

Apr 2, 2012, 2:38 PM

Post #3 of 51 (437 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

On 02Apr2012 13:37, Victor Stinner <victor.stinner [at] gmail> wrote:
| > 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?).

That is deliberate. People can easily write fallback like this:

clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC)

With exceptions one gets a complicated try/except/else chain that is
much harder to read. With a second fallback the try/except gets even
worse.

If one wants an exception it is easy to follow up with:

if not clock:
raise RunTimeError("no suitable clocks on offer on this platform")

| get_clock() doesn't remember if a clock works or not (if it raises an
| OSError) and does not fallback to the next clock on error. See
| "pseudo-codes" in the PEP 418.

I presume the available clocks are all deduced from the platform. Your
pseudo code checks for OSError at fetch-the-clock time. I expect that
to occur once when the module is loaded, purely to populate the table
of avaiable platform clocks.

If you are concerned about clocks being available/unavailable at
different times (unplugging the GPS peripheral? just guessing here)
that will have to raise OSError during the now() call (assuming the
clock even exposes the failure; IMO it should when now() is called).

| The idea of flags attached to each clock is interesting, but I don't
| like the need of different list of clocks.

There's no need, just quality of implementation for the monotonic()/hires()
convenience calls, which express the (hoped to be common) policy of what
clock to offer for each.

We've just had pages upon pages of discussion about what clock to offer
for the rather bald monotonic() (et al) calls. The ordering of the
MONTONIC_CLOCKS list would express the result of that discussion,
in that the "better" clocks come first.

| Should I use
| MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and
| high-resolution clock?

Note that you don't need to provide a clock list at all; get_clock(0
will use ALL_CLOCKS by default, and hires() and monotonic() should each
have their own default list.

I'll put in montonic() and montonic_clock(clocklist=MONOTONIC_CLOCKS)
into the skeleton to make this clear; I see I've omitted them.

Regarding the choice itself: as the _caller_ (not the library author),
you must decide what you want most. You're already planning offering
monotonic() and hires() calls without my proposal! Taking your query "Should
I use MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and
high-resolution clock" is _already_ a problem. Of course you must call
monotonic() or hires() first under the current scheme, and must answer this
question anyway. Do you prefer hires? Use it first! No preference? Then the
question does not matter.

If I, as the caller, have a preference then it is obvious what to use.
If I do not have a preference then I can just call get_clock() with both
flags and then arbitrarily fall back to hires() or monotonic() if that
does not work.

| It would be simpler to have only one global and
| *private* list.

No. No no no no no!

The whole point is to let the user be _able_ to control the choices to a
fair degree without platform special knowledge. The lists are
deliberately _optional_ parameters and anyway hidden in the hires() and
monotonic() convenince functions; the user does not need to care about
them. But the picky user may! The lists align exactly one to one with
the feature flags, so there is no special knowledge present here that is
not already implicit in publishing the feature flags.

| If you have only one list of clocks, how do sort the list to get
| QueryPerformanceCounter when the user asks for highres and
| GetTickCount when the user asks for monotonic?

This is exactly why there are supposed to be different lists.
You have just argued against your objection above.

| The "if clock.flags &
| flags == flags:" test in get_clock() is maybe not enough. I suppose
| that we would have the following flags for Windows functions:
|
| QueryPerformanceCounter.flags = T_HIRES
| GetTickCount.flags = T_MONOTONIC | T_STEADY
|
| (or maybe QueryPerformanceCounter.flags = T_HIRES | T_MONOTONIC ?)

Obviously these depend on the clock characteristics. Is
QueryPerformanceCounter monotonic?

| monotonic_clock() should maybe try to get a clock using the following
| list of conditions:
| - T_MONOTONIC | T_STEADY
| - T_MONOTONIC | T_HIGHRES
| - T_MONOTONIC

Sure, seems reasonable. That is library internal policy _for the convenince
monotonic() function()_.

| The T_HIGHRES flag in unclear, even in the PEP. According to the PEP,
| any monotonic clock is considered as a "high-resolution" clock. Do you
| agree?

Not particularly. I easily can imagine a clock with one second resolution
hich was monotonic. I would not expect it to have the T_HIRES flag.
Example: a synthetic monotonic clock based on a V7 UNIX time() call.

But, if it _happens_ that all the monotonic clocks are also hires, so be
it. That would be an empirical outcome, not policy.

| So we would have:
|
| GetTickCount.flags = T_MONOTONIC | T_STEADY | T_HIGHRES
|
| Even if GetTickCount has only an accuracy of 15 ms :-/

T_HIGHRES is a quality call, surely? If 15ms is too sloppy for a "high
resolution, the is should _not_ have the T_HIRES flag.

| Can list please give the list of flags of each clocks listed in the
| PEP? Only clocks used for time.time, time.monotonic and time.highres
| (not process and thread clocks nor QueryUnbiasedInterruptTime).
|
| >      # get a clock object - often a singleton under the hood
| >      T = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_STEADY|T_HIRES)
| >      # what kind of clock did I get?
| >      print T.flags
| >      # get the current time
| >      now = T.now
|
| The API looks much more complex than the API proposed in PEP 418 just
| to get the time. You have to call a function to get a function, and
| then call the function, instead of just calling a function directly.

One could have a flat interface as in the PEP, but then the results are
not inspectable; the user cannot find out what specific clock, or even
kind of clock, was used for the result returned.

Unless you want to subclass float for the return values. You could return
instances of a float with meta information pointing at the clock used to
provide it. I'm -0.5 on that idea.

Another advantage of returning a clock object is that it avoids the
difficulty of switching implementations behind the user's back, an issue
raised in the discussion and rightly rejected as a bad occurence.

If the user is handed a clock object, _they_ keep the "current clock in
use" state by by having the object reference.

| Instead of returning an object with a now() method, I would prefer to
| get directly the function getting time, and another function to get
| "metadata" of the clock.

Then they're disconnected. How do I know the get-metadata call accesses
the clock I just used? Only by having library internal global state.

I agree some people probably want the flat "get me the time" call, and have
no real objection to such existing. But I strongly object to not giving
the user control over what they use, and the current API offers no
control.

| > This removes policy from the library functions and makes it both simple
| > and obvious in the user's calling code, and also makes it possible for
| > the user to inspect the clock and find out what quality/flavour of clock
| > they got.
|
| I'm not sure that users understand correctly differences between all
| these clocks and are able to use your API correctly. How should I
| combinese these 3 flags (T_HIRES, T_MONOTONIC and T_STEADY)? Can I use
| any combinaison?

Of course. Just as with web searches, too many flags may get you an
empty result on some platforms, hence the need to fall back. But the
_nature_ of the fallback should be in the user's hands. The hires() et
al calls can of course offer convenient presupplied fallback according
to the preconceptions of the library authors, hopefully well tuned to
common users' needs. But if should not be the only mode offered, because
you don't know the user's needs.

| Which flags are "portable"? Or should I always use an explicit
| fallback to ensure getting a clock on any platform?

All the flag are portable, but if the platform doesn't supply a clock
with the requested flags, even if there's only one flag, the correct
result is "None" for the clock offered.

Note you can supply no flags!

You can always fall all the way back to 0 for the flags; in the skeleton
provided that will get you UNIXClock, which is a wrapper for the
existing time.time(). In fact, I'll make the flags parameter also
optional for get_clock(), defaulting to 0, to make that easy. That
becomes your totally portable call:-)

| Could you please update your code according to my remarks? I will try
| to integrate it into the PEP. A PEP should list all alternatives!

Surely.

The only updates I can see are to provide the flat interface
(instead of via clock-object indirection) and the missing hires_clock()
and monotonic_clock() convenience methods.

I'll do that. Followup post shortly with new code URL.
Would you propose other specific additions?

Cheers,
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

Whatever is not nailed down is mine. What I can pry loose is not nailed
down. - Collis P. Huntingdon
_______________________________________________
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


cs at zip

Apr 2, 2012, 2:51 PM

Post #4 of 51 (437 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

On 03Apr2012 07:38, I wrote:
| On 02Apr2012 13:37, Victor Stinner <victor.stinner [at] gmail> wrote:
| | Could you please update your code according to my remarks? I will try
| | to integrate it into the PEP. A PEP should list all alternatives!

New code here:
https://bitbucket.org/cameron_simpson/css/src/91848af8663b/lib/python/cs/clockutils.py

Diff:
https://bitbucket.org/cameron_simpson/css/changeset/91848af8663b

Changelog: updates based on suggestions from Victor Stinner: "flat" API
calls to get time directly, make now() a method instead of a property,
default flags for get_clock(), adjust hr_clock() to hires_clock(0 for
consistency.

Cheers,
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

Q: How does a hacker fix a function which doesn't work for all of the elements in its domain?
A: He changes the domain.
- Rich Wareham <rjw57 [at] hermes>
_______________________________________________
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


cs at zip

Apr 2, 2012, 3:05 PM

Post #5 of 51 (437 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

On 03Apr2012 07:51, I wrote:
| Changelog: updates based on suggestions from Victor Stinner: "flat" API
| calls to get time directly, make now() a method instead of a property,
| default flags for get_clock(), adjust hr_clock() to hires_clock(0 for
| consistency.

BTW, I'd also happily change T_HIRES to HIRES and so forth. They're hard to
type and read at present. The prefix is a hangover from old C coding habits,
with no namespaces.
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

If you don't live on the edge, you're taking up too much space. - t-shirt
_______________________________________________
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


cs at zip

Apr 2, 2012, 3:44 PM

Post #6 of 51 (438 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

On 03Apr2012 07:38, I wrote:
| On 02Apr2012 13:37, Victor Stinner <victor.stinner [at] gmail> wrote:
| | Should I use
| | MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and
| | high-resolution clock?
|
| Note that you don't need to provide a clock list at all; get_clock(0
| will use ALL_CLOCKS by default, and hires() and monotonic() should each
| have their own default list.
[...]
| | It would be simpler to have only one global and
| | *private* list.
[...]
| The whole point is to let the user be _able_ to control the choices to a
| fair degree without platform special knowledge.

On some reflection I may lean a little more Victor's way here:

I am still very much of the opinion that there should be multiple clock lists
so that hires() can offer the better hires clocks first and so forth.

However, perhaps I misunderstood and he was asking if he needed to name
a list to get a hires clock etc. This intent is not to need to, via the
convenience functions.

Accordingly, maybe the list names needn't be published, and may complicate
the published interface even though they're one to one with the flags.

It would certainly up the ante slightly f we added more
flags some time later. (For example, I think any synthetic clocks
such as the caching example in the skeleton should probably have a
SYNTHETIC flag. You might never ask for it, but you should be able to
check for it.

(I personally suspect some of the OS clocks are themselves synthetic,
but no matter...)

The flip side of this of course is that if the list names are private then
the get_clock() and hires() etc functions almost mandatorially need the
optional all_clocks=False parameter mooted in a sibling post; the really
picky user needs a way to iterate over the available clocks to make a fine
grained decision. On example would be to ask for monotonic clocks but omit
synthetic ones (there's a synthetic clock in the skeleton though I don't
partiularly expect one in reality - that really is better in a broader
"*utils" module; I also do NOT want to get into complicated parameters
to say these flags but not _those_ flags and so forth for other metadata.

And again, an external module offering synthetic clocks could easily want to
be able to fetch the existing and augument the list with its own, then use
that with the get_clock() interfaces.

So in short I think:

- there should be, internally at least, multiple lists for quality of
returned result

- there should be a way to iterate over the available clocks, probably
via an all_clocks paramater instead of a public list name

Cheers,
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

There is hopeful symbolism in the fact that flags do not wave in a vacuum.
- Arthur C. Clarke
_______________________________________________
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


regebro at gmail

Apr 2, 2012, 10:51 PM

Post #7 of 51 (433 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

I like the aim of letting the user control what clock it get, but I
find this API pretty horrible:

> clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC)

Just my 2 groszy.

//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/list-python-dev%40lists.gossamer-threads.com


cs at zip

Apr 2, 2012, 11:03 PM

Post #8 of 51 (432 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

On 03Apr2012 07:51, Lennart Regebro <regebro [at] gmail> wrote:
| I like the aim of letting the user control what clock it get, but I
| find this API pretty horrible:
|
| >  clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC)

FWIW, the leading "T_" is now gone, so it would now read:

clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC)

If the symbol names are not the horribleness, can you qualify what API
you would like more?
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

We had the experience, but missed the meaning. - T.S. Eliot
_______________________________________________
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


breamoreboy at yahoo

Apr 3, 2012, 1:03 AM

Post #9 of 51 (430 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

On 03/04/2012 07:03, Cameron Simpson wrote:
> On 03Apr2012 07:51, Lennart Regebro<regebro [at] gmail> wrote:
> | I like the aim of letting the user control what clock it get, but I
> | find this API pretty horrible:
> |
> |> clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC)
>
> FWIW, the leading "T_" is now gone, so it would now read:
>
> clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC)
>
> If the symbol names are not the horribleness, can you qualify what API
> you would like more?

I reckon the API is ok given that you don't have to supply the flags,
correct?

A small point but I'm with (I think) Terry Reedy and Steven D'Aprano in
that hires is an English word, could you please substitute highres and
HIGHRES, thanks.

--
Cheers.

Mark Lawrence.

_______________________________________________
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


cs at zip

Apr 3, 2012, 1:43 AM

Post #10 of 51 (430 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

On 03Apr2012 09:03, Mark Lawrence <breamoreboy [at] yahoo> wrote:
| On 03/04/2012 07:03, Cameron Simpson wrote:
| > On 03Apr2012 07:51, Lennart Regebro<regebro [at] gmail> wrote:
| > | I like the aim of letting the user control what clock it get, but I
| > | find this API pretty horrible:
| > |
| > |> clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC)
| >
| > FWIW, the leading "T_" is now gone, so it would now read:
| >
| > clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC)
| >
| > If the symbol names are not the horribleness, can you qualify what API
| > you would like more?
|
| I reckon the API is ok given that you don't have to supply the flags,
| correct?

That's right. And if the monotonic() or monotonic_clock() functions
(or the hires* versions if suitable) do what you want you don't even
need that. You only need the "or" style to choose your own fallback
according to your own criteria.

| A small point but I'm with (I think) Terry Reedy and Steven D'Aprano in
| that hires is an English word, could you please substitute highres and
| HIGHRES, thanks.

I have the same issue and would be happy to do it. Victor et al, how do
you feel about this? People have been saying "hires" throughout the
threads I think, but I for one would be slightly happier with "highres".

Cheers,
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

I bested him in an Open Season of scouring-people's-postings-looking-for-
spelling-errors. - kevin [at] rotag (Kevin Darcy)
_______________________________________________
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


regebro at gmail

Apr 3, 2012, 7:09 AM

Post #11 of 51 (431 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

On Tue, Apr 3, 2012 at 08:03, Cameron Simpson <cs [at] zip> wrote:
> clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC)
>
> If the symbol names are not the horribleness, can you qualify what API
> you would like more?

Well, get_clock(monotonic=True, highres=True) would be a vast
improvement over get_clock(MONOTONIC|HIRES). I also think it should
raise an error if not found. The clarity and easy of use of the API is
much more important than how much you can do in one line.

//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/list-python-dev%40lists.gossamer-threads.com


ethan at stoneleaf

Apr 3, 2012, 9:07 AM

Post #12 of 51 (426 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

Lennart Regebro wrote:
> On Tue, Apr 3, 2012 at 08:03, Cameron Simpson <cs [at] zip> wrote:
>> clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC)
>>
>> If the symbol names are not the horribleness, can you qualify what API
>> you would like more?
>
> Well, get_clock(monotonic=True, highres=True) would be a vast
> improvement over get_clock(MONOTONIC|HIRES).

Allowing get_clock(True, True)? Ick. My nomination would be
get_clock(MONOTONIC, HIGHRES) -- easier on the eyes with no |.

> I also think it should
> raise an error if not found. The clarity and easy of use of the API is
> much more important than how much you can do in one line.

What's unclear about returning None if no clocks match?

Cheers,
~Ethan~
_______________________________________________
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


cs at zip

Apr 3, 2012, 2:42 PM

Post #13 of 51 (420 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

On 03Apr2012 09:07, Ethan Furman <ethan [at] stoneleaf> wrote:
| Lennart Regebro wrote:
| > On Tue, Apr 3, 2012 at 08:03, Cameron Simpson <cs [at] zip> wrote:
| >> clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC)
| >>
| >> If the symbol names are not the horribleness, can you qualify what API
| >> you would like more?
| >
| > Well, get_clock(monotonic=True, highres=True) would be a vast
| > improvement over get_clock(MONOTONIC|HIRES).
|
| Allowing get_clock(True, True)? Ick. My nomination would be
| get_clock(MONOTONIC, HIGHRES) -- easier on the eyes with no |.

get_clock already has two arguments - you can optionally hand it a clock
list - that's used by monotonic_clock() and hires_clock().

Have a quick glance at:

https://bitbucket.org/cameron_simpson/css/src/tip/lib/python/cs/clockutils.py

(I finally found out how to point at the latest revision on BitBucket;
it's not obvious from the web interface itself.)

| > I also think it should
| > raise an error if not found. The clarity and easy of use of the API is
| > much more important than how much you can do in one line.

How much you can do _clearly_ in one line is a useful metric.

| What's unclear about returning None if no clocks match?

The return of None is very deliberate. I _want_ user specified fallback
to be concise and easy. The example:

clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC)

seems to satisfy both these criteria to my eye. Raising an exception
makes user fallback a royal PITA, with a horrible try/except cascade
needed.

Exceptions are all very well when there is just one thing to do: parse
this or fail, divide this by that or fail. If fact they're the very
image of "do this one thing or FAIL". They are not such a good match for do
this thing or that thing or this other thing.

When you want a simple linear cascade of choices, Python's short circuiting
"or" operator is a very useful thing. Having an obsession with exceptions is
IMO unhealthy.

Cheers,
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

Because of its special customs, crossposting between alt.peeves and normal
newsgroups is discouraged. - Cameron Spitzer
_______________________________________________
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


ethan at stoneleaf

Apr 3, 2012, 3:08 PM

Post #14 of 51 (421 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

Cameron Simpson wrote:
> get_clock already has two arguments - you can optionally hand it a clock
> list - that's used by monotonic_clock() and hires_clock().

def get_clock(*flags, *, clocklist=None):
''' Return a Clock based on the supplied `flags`.
The returned clock shall have all the requested flags.
If no clock matches, return None.
'''
wanted = 0
for flag in flags:
wanted |= flag
if clocklist is None:
clocklist = ALL_CLOCKS
for clock in clocklist:
if clock.flags & wanted == wanted:
return clock.factory()
return None

Would need to make *flags change to the other *_clock functions.


> Have a quick glance at:
>
> https://bitbucket.org/cameron_simpson/css/src/tip/lib/python/cs/clockutils.py

Thanks.


> The return of None is very deliberate. I _want_ user specified fallback
> to be concise and easy. The example:
>
> clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC)

Which would become:

clock = get_clock(MONOTONIC, HIGHRES) or get_clock(MONOTONIC)

+1 to returning None


> Exceptions are all very well when there is just one thing to do: parse
> this or fail, divide this by that or fail. If fact they're the very
> image of "do this one thing or FAIL". They are not such a good match for do
> this thing or that thing or this other thing.
>
> When you want a simple linear cascade of choices, Python's short circuiting
> "or" operator is a very useful thing. Having an obsession with exceptions is
> IMO unhealthy.

Another +1.

~Ethan~
_______________________________________________
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


cs at zip

Apr 3, 2012, 4:38 PM

Post #15 of 51 (415 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

On 03Apr2012 15:08, Ethan Furman <ethan [at] stoneleaf> wrote:
| Cameron Simpson wrote:
| > get_clock already has two arguments - you can optionally hand it a clock
| > list - that's used by monotonic_clock() and hires_clock().
|
| def get_clock(*flags, *, clocklist=None):

I presume that bare "*," is a typo. Both my python2 and python3 commands
reject it.

[...]
| wanted = 0
| for flag in flags:
| wanted |= flag
[...]

I could do this. I think I'm -0 on it, because it doesn't seem more
expressive to my eye than the straight make-a-bitmask "|" form.
Other opinions?

| Would need to make *flags change to the other *_clock functions.

Yep.

| > The return of None is very deliberate. I _want_ user specified fallback
| > to be concise and easy. The example:
| > clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC)
|
| Which would become:
| clock = get_clock(MONOTONIC, HIGHRES) or get_clock(MONOTONIC)
|
| +1 to returning None
|
| > Exceptions are all very well when there is just one thing to do: parse
| > this or fail, divide this by that or fail. If fact they're the very
| > image of "do this one thing or FAIL". They are not such a good match for do
| > this thing or that thing or this other thing.

Another thought that occurred in the shower was that get_clock() et al
are inquiry functions, and returning None is very sensible there.

monotonic() et al are direct use functions, which should raise an exception
if unavailable so that code like:

t0 = monotonic()
.......
t1 = monotonic()

does not become littered with checks for special values like None.

I consider this additional reason to return None from get_clock().

Cheers,
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

DON'T DRINK SOAP! DILUTE DILUTE! OK!
- on the label of Dr. Bronner's Castile Soap
_______________________________________________
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

Apr 3, 2012, 4:45 PM

Post #16 of 51 (412 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

> | 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 list of set of flags? Example:

haypo_steady = get_clock(MONOTONIC|STEADY, STEADY, MONOTONIC, REALTIME)
# try to get a monotonic and steady clock,
# or fallback to a steady clock,
# or fallback to a monotonic clock,
# or fallback to the system clock

haypo_perf_counter = get_clock(HIGHRES, MONOTONIC|STEADY, STEADY,
MONOTONIC, REALTIME)
# try to get a high-resolution clock
# or fallback to a monotonic and steady clock,
# or fallback to a steady clock,
# or fallback to a monotonic clock,
# or fallback to the system clock

On Windows, haypo_steady should give GetTickCount (MONOTONIC|STEADY)
and haypo_perf_counter should give QueryPerformanceCounter
(MONOTONIC|HIGHRES).

Hum, I'm not sure that haypo_highres uses the same clocks than
time.perf_counter() in the PEP.

> If one wants an exception it is easy to follow up with:
>
>  if not clock:
>    raise RunTimeError("no suitable clocks on offer on this platform")

And if don't read the doc carefuly and forget the test, you can a
"NoneType object is not callable" error.

> | get_clock() doesn't remember if a clock works or not (if it raises an
> | OSError) and does not fallback to the next clock on error. See
> | "pseudo-codes" in the PEP 418.
>
> I presume the available clocks are all deduced from the platform. Your
> pseudo code checks for OSError at fetch-the-clock time. I expect that
> to occur once when the module is loaded, purely to populate the table
> of avaiable platform clocks.

It's better to avoid unnecessary system calls at startup (when the
time module is loaded), but you may defer the creation of the clock
list, or at least of the flags of each clock.

> Note that you don't need to provide a clock list at all; get_clock(0
> will use ALL_CLOCKS by default, and hires() and monotonic() should each
> have their own default list.

A list of clocks and a function are maybe redundant. Why not only
providing a function?

> Regarding the choice itself: as the _caller_ (not the library author),
> you must decide what you want most. You're already planning offering
> monotonic() and hires() calls without my proposal!

My PEP starts with use cases: it proposes one clock per use case.
There is no "If you need a monotonic, steady and high-resolution clock
..." use case.

The "highres" name was confusing, I just replaced it with
time.perf_counter() (thanks Antoine for the name!).
time.perf_counter() should be used for benchmarking and profiling.

> Taking your query "Should
> I use MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and
> high-resolution clock" is _already_ a problem. Of course you must call
> monotonic() or hires() first under the current scheme, and must answer this
> question anyway. Do you prefer hires? Use it first! No preference? Then the
> question does not matter.

I mean having to choose the flags *and* the list of clocks is hard. I
would prefer to only have to choose flags or only the list of clocks.
The example was maybe not the best one.

> | If you have only one list of clocks, how do sort the list to get
> | QueryPerformanceCounter when the user asks for highres and
> | GetTickCount when the user asks for monotonic?
>
> This is exactly why there are supposed to be different lists.
> You have just argued against your objection above.

You can solve this issue with only one list of clocks if you use the
right set of flags.

> | So we would have:
> |
> | GetTickCount.flags = T_MONOTONIC | T_STEADY | T_HIGHRES
> |
> | Even if GetTickCount has only an accuracy of 15 ms :-/
>
> T_HIGHRES is a quality call, surely? If 15ms is too sloppy for a "high
> resolution, the is should _not_ have the T_HIRES flag.

So what is the minimum resolution and/or accuracy of the HIGHRES flag?

> | Could you please update your code according to my remarks? I will try
> | to integrate it into the PEP. A PEP should list all alternatives!
>
> Surely.
>
> The only updates I can see are to provide the flat interface
> (instead of via clock-object indirection) and the missing hires_clock()
> and monotonic_clock() convenience methods.

A full implementation would help to decide which API is the best one.
"Full" implementation:

- define all convinience function
- define all list of clocks
- define flags of all clocks listed in the PEP 418: clocks used in
the pseudo-code of time.steady and time.perf_counter, and maybe also
time.time

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


ncoghlan at gmail

Apr 3, 2012, 4:46 PM

Post #17 of 51 (412 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

On Wed, Apr 4, 2012 at 9:38 AM, Cameron Simpson <cs [at] zip> wrote:
> I could do this. I think I'm -0 on it, because it doesn't seem more
> expressive to my eye than the straight make-a-bitmask "|" form.
> Other opinions?

Yes. I've been mostly staying out of the PEP 418 clock discussion
(there are enough oars in there already), but numeric flags are
unnecessarily hard to debug. Use strings as your constants unless
there's a compelling reason not to.

Seeing "('MONOTONIC', 'HIGHRES')" in a debugger or exception message
is a lot more informative than seeing "3".

Regards,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
_______________________________________________
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


greg.ewing at canterbury

Apr 3, 2012, 5:04 PM

Post #18 of 51 (413 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

Cameron Simpson wrote:
> People have been saying "hires" throughout the
> threads I think, but I for one would be slightly happier with "highres".

hirez?

--
Greg
_______________________________________________
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


breamoreboy at yahoo

Apr 3, 2012, 5:18 PM

Post #19 of 51 (414 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

On 04/04/2012 01:04, Greg Ewing wrote:
> Cameron Simpson wrote:
>> People have been saying "hires" throughout the
>> threads I think, but I for one would be slightly happier with "highres".
>
> hirez?
>

IMHO still too easy to read as hires. Or is it? Bah I'm going to bed
and will think about it, night all.

--
Cheers.

Mark Lawrence.

_______________________________________________
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


cs at zip

Apr 3, 2012, 7:46 PM

Post #20 of 51 (413 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

On 04Apr2012 01:45, Victor Stinner <victor.stinner [at] gmail> wrote:
| > | 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 list of set of flags? Example:
|
| haypo_steady = get_clock(MONOTONIC|STEADY, STEADY, MONOTONIC, REALTIME)
| # try to get a monotonic and steady clock,
| # or fallback to a steady clock,
| # or fallback to a monotonic clock,
| # or fallback to the system clock

That's interesting. Ethan Furman suggested multiple arguments to be
combined, whereas yours bundles multiple search criteria in one call.

While it uses a bitmask as mine does, this may get cumbersome if we went
with Nick's "use strings!" suggestion.

| haypo_perf_counter = get_clock(HIGHRES, MONOTONIC|STEADY, STEADY,
| MONOTONIC, REALTIME)
| # try to get a high-resolution clock
| # or fallback to a monotonic and steady clock,
| # or fallback to a steady clock,
| # or fallback to a monotonic clock,
| # or fallback to the system clock
|
| On Windows, haypo_steady should give GetTickCount (MONOTONIC|STEADY)
| and haypo_perf_counter should give QueryPerformanceCounter
| (MONOTONIC|HIGHRES).

Sounds ok to me. I am not familiar with the Windows counters and am
happy to take your word for it.

| Hum, I'm not sure that haypo_highres uses the same clocks than
| time.perf_counter() in the PEP.
|
| > If one wants an exception it is easy to follow up with:
| >  if not clock:
| >    raise RunTimeError("no suitable clocks on offer on this platform")
|
| And if don't read the doc carefuly and forget the test, you can a
| "NoneType object is not callable" error.

Excellent! An exception either way! Win win!

| > | get_clock() doesn't remember if a clock works or not (if it raises an
| > | OSError) and does not fallback to the next clock on error. See
| > | "pseudo-codes" in the PEP 418.
| >
| > I presume the available clocks are all deduced from the platform. Your
| > pseudo code checks for OSError at fetch-the-clock time. I expect that
| > to occur once when the module is loaded, purely to populate the table
| > of avaiable platform clocks.
|
| It's better to avoid unnecessary system calls at startup (when the
| time module is loaded), but you may defer the creation of the clock
| list, or at least of the flags of each clock.

Yes indeed. I think this should be deferred until use.

| > Note that you don't need to provide a clock list at all; get_clock(0
| > will use ALL_CLOCKS by default, and hires() and monotonic() should each
| > have their own default list.
|
| A list of clocks and a function are maybe redundant. Why not only
| providing a function?

Only because the function currently only returns one clock.
The picky user may want to peruse all the clocks inspecting other
metadata (precision etc) than the coarse flag requirements.

There should be a way to enumerate the available clock implementation;
in my other recent post I suggest either lists (as current), a
get_clocks() function, or a mode parameter to get_clock() such as
_all_clocks, defaulting to False.

| > Regarding the choice itself: as the _caller_ (not the library author),
| > you must decide what you want most. You're already planning offering
| > monotonic() and hires() calls without my proposal!
|
| My PEP starts with use cases: it proposes one clock per use case.
| There is no "If you need a monotonic, steady and high-resolution clock
| ..." use case.

Yes. but this is my exact objection to the "just provide hires() and
steady() and/or monotonic()" API; the discussion to date is littered
with "I can't imagine wanting to do X" style remarks. We should not be
trying to enumerate the user case space exhaustively. I'm entirely in
favour of your list of use cases and the approach of providing hires() et
al to cover the thought-common use cases. But I feel we really _must_
provide a way for the user with a not-thought-of use case to make an
arbitrary decision.

get_clock() provides a simple cut at the "gimme a suitable clock"
approach, with the lists or other "get me an enumeration of the
available clocks" mechanism for totally ad hoc perusal if the need
arises.

This is also my perhaps unstated concern with Guido's "the more I think about
it, the more I believe these functions should have very loose guarantees, and
instead just cater to common use cases -- availability of a timer with
minimal fuss is usually more important than the guarantees"
http://www.mail-archive.com/python-dev [at] python/msg66173.html

The easy to use hires() etc must make very loose guarentees or they will
be useless too often. That looseness is fine in some ways - it provides
availability on many platforms (all?) and discourages the user from
hoping for too much and thus writing fragile code. But it also PREVENTS
the user from obtaining a really good clock if it is available (where
"good" means their partiuclar weirdo feature requirements).

So I think there should be both - the easy and simple calls, and a
mecahnism for providing all clocks for the user to chose with arbitrary
criteria and fallback.

| The "highres" name was confusing, I just replaced it with
| time.perf_counter() (thanks Antoine for the name!).
| time.perf_counter() should be used for benchmarking and profiling.

I've been wondering; do we distinguish between clocks and counters. In my
mind a clock or timer has a very linear relationship with "real time",
the wall clock. A counter, by comparison, may measure CPU cycles or
kernel timeslice ticks or python opcode counts or any number of other
time-like resource consumption things.

I've been presuming we're concerned here with "clocks" and not counters.

| > Taking your query "Should
| > I use MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and
| > high-resolution clock" is _already_ a problem. Of course you must call
| > monotonic() or hires() first under the current scheme, and must answer this
| > question anyway. Do you prefer hires? Use it first! No preference? Then the
| > question does not matter.
|
| I mean having to choose the flags *and* the list of clocks is hard. I
| would prefer to only have to choose flags or only the list of clocks.
| The example was maybe not the best one.

Yah; I think I made a followup post where I realised you may have meant
this.

The use of default arguments is meant to make it easy to use flags
and/or lists or even neither (which for get_clock() at least would
always get you a clock because a wrapper for time.time() is always
provided). In my mind, usually just flags of course.

| > | If you have only one list of clocks, how do sort the list to get
| > | QueryPerformanceCounter when the user asks for highres and
| > | GetTickCount when the user asks for monotonic?
| >
| > This is exactly why there are supposed to be different lists.
| > You have just argued against your objection above.
|
| You can solve this issue with only one list of clocks if you use the
| right set of flags.

No you can't, not in general. If there are multiple clocks honouring
those flags you only ever get the first one in the list. The point of the
MONOTONIC_CLOCKS list etc is that the lists may be differently ordered
to provide quality of clock within that domain. Suppose I ask for
steady_clock(MONOTONIC); I would probably prefer a more-steady clock
over a more-precise/hires clock. And converse desires when asking for
hires_clock(). So different list orders, at least in principle.

If it turns out empirically that this isn't the case then all the names
can in fact refer to the same list. But offering only one list _name_
prevents offering these nuances when other platforms/clocks come in the
future.

| > | So we would have:
| > |
| > | GetTickCount.flags = T_MONOTONIC | T_STEADY | T_HIGHRES
| > |
| > | Even if GetTickCount has only an accuracy of 15 ms :-/
| >
| > T_HIGHRES is a quality call, surely? If 15ms is too sloppy for a "high
| > resolution, the is should _not_ have the T_HIRES flag.
|
| So what is the minimum resolution and/or accuracy of the HIGHRES flag?

No idea. But you must in principle have one in mind to offer the hires()
call at all in the PEP, or be prepared to merely offer the most hires
clock available regardless. In this latter case you would always mark
that clock as having the HIRES flag and the problem is solved. It would
be good to have metadata to indicate how hires a partiulcar clock is.

| > | Could you please update your code according to my remarks? I will try
| > | to integrate it into the PEP. A PEP should list all alternatives!
| >
| > Surely.
| >
| > The only updates I can see are to provide the flat interface
| > (instead of via clock-object indirection) and the missing hires_clock()
| > and monotonic_clock() convenience methods.
|
| A full implementation would help to decide which API is the best one.
| "Full" implementation:
|
| - define all convinience function
| - define all list of clocks

Ok. My current code is here, BTW:
https://bitbucket.org/cameron_simpson/css/src/tip/lib/python/cs/clockutils.py
(Finally found a revision independent URL on bitbucket.)

| - define flags of all clocks listed in the PEP 418: clocks used in
| the pseudo-code of time.steady and time.perf_counter, and maybe also
| time.time

I'll make one. It will take a little while. Will post again when ready. At
present the code compiles and runs (albeit with no platform specific
clocks:-) This table may require fictitious code. Should still compile
I guess...

Cheers,
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

The right to be heard does not include the right to be taken seriously.
- Hubert Horatio Humphrey
_______________________________________________
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


p.f.moore at gmail

Apr 4, 2012, 1:21 AM

Post #21 of 51 (406 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

(Sorry, should have sent to the list).

On 4 April 2012 01:04, Greg Ewing <greg.ewing [at] canterbury> wrote:
> Cameron Simpson wrote:
>>
>> People have been saying "hires" throughout the
>> threads I think, but I for one would be slightly happier with "highres".
>
>
> hirez?

What's wrong with high_resolution?
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


regebro at gmail

Apr 4, 2012, 8:47 AM

Post #22 of 51 (402 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

On Tue, Apr 3, 2012 at 18:07, Ethan Furman <ethan [at] stoneleaf> wrote:
> What's unclear about returning None if no clocks match?

Nothing, but having to check error values on return functions are not
what you typically do in Python. Usually, Python functions that fail
raise an error. Please don't force Python users to write pseudo-C code
in Python.

//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/list-python-dev%40lists.gossamer-threads.com


ethan at stoneleaf

Apr 4, 2012, 9:18 AM

Post #23 of 51 (403 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

Lennart Regebro wrote:
> On Tue, Apr 3, 2012 at 18:07, Ethan Furman <ethan [at] stoneleaf> wrote:
>> What's unclear about returning None if no clocks match?
>
> Nothing, but having to check error values on return functions are not
> what you typically do in Python. Usually, Python functions that fail
> raise an error. Please don't force Python users to write pseudo-C code
> in Python.

You mean like the dict.get() function?

--> repr({}.get('missing'))
'None'

Plus, failure mode is based on intent: if the intent is "Give a clock
no matter what", then yes, an exception when that's not possible is the
way to go.

But if the intent is "Give me a clock that matches this criteria" then
returning None is perfectly reasonable.

~Ethan~
_______________________________________________
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


phd at phdru

Apr 4, 2012, 10:44 AM

Post #24 of 51 (409 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

On Wed, Apr 04, 2012 at 05:47:16PM +0200, Lennart Regebro wrote:
> On Tue, Apr 3, 2012 at 18:07, Ethan Furman <ethan [at] stoneleaf> wrote:
> > What's unclear about returning None if no clocks match?
>
> Nothing, but having to check error values on return functions are not
> what you typically do in Python. Usually, Python functions that fail
> raise an error.

Absolutely. "Errors should never pass silently."

> Please don't force Python users to write pseudo-C code in Python.

+1. Pythonic equivalent of "get_clock(THIS) or get_clok(THAT)" is

for flag in (THIS, THAT):
try:
clock = get_clock(flag)
except:
pass
else:
break
else:
raise ValueError('Cannot get clock, tried THIS and THAT')

Oleg.
--
Oleg Broytman http://phdru.name/ phd [at] phdru
Programmers don't die, they just GOSUB without RETURN.
_______________________________________________
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


g.brandl at gmx

Apr 4, 2012, 10:47 AM

Post #25 of 51 (403 views)
Permalink
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) [In reply to]

Am 04.04.2012 18:18, schrieb Ethan Furman:
> Lennart Regebro wrote:
>> On Tue, Apr 3, 2012 at 18:07, Ethan Furman <ethan [at] stoneleaf> wrote:
>>> What's unclear about returning None if no clocks match?
>>
>> Nothing, but having to check error values on return functions are not
>> what you typically do in Python. Usually, Python functions that fail
>> raise an error. Please don't force Python users to write pseudo-C code
>> in Python.
>
> You mean like the dict.get() function?
>
> --> repr({}.get('missing'))
> 'None'

Strawman: this is not a failure.

Georg

_______________________________________________
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

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.