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)

 

 

Python dev RSS feed   Index | Next | Previous | View Threaded


cs at zip

Apr 1, 2012, 5:43 PM

Post #1 of 51 (423 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 (409 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 (406 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 (405 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 (405 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 (406 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 (402 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 (399 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 (398 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 (398 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 (399 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 (395 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 (389 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 (387 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 (383 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 (380 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 (382 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 (381 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 (382 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 (381 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 (373 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 (370 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 (372 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 (375 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 (372 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


ethan at stoneleaf

Apr 4, 2012, 11:03 AM

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

Oleg Broytman wrote:
> 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."

Again, what's the /intent/? No matching clocks does not have to be an
error.


>> 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')


Wow -- you'd rather write nine lines of code instead of three?

clock = get_clock(THIS) or get_clock(THAT)
if clock is None:
raise ValueError('Cannot get clock, tried THIS and THAT')

~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


ethan at stoneleaf

Apr 4, 2012, 11:06 AM

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

Georg Brandl wrote:
> 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.

Also not a very good example -- if 'missing' was there with a value of
None the two situations could not be distinguished with the one call.

At any rate, the point is that there is nothing inherently wrong nor
unPythonic about a function returning None instead of raising an exception.

~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, 12:24 PM

Post #28 of 51 (279 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 11:03:02AM -0700, Ethan Furman wrote:
> Oleg Broytman wrote:
> > . 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')
>
>
> Wow -- you'd rather write nine lines of code instead of three?
>
> clock = get_clock(THIS) or get_clock(THAT)
> if clock is None:
> raise ValueError('Cannot get clock, tried THIS and THAT')

Yes - to force people to write the last two lines. Without forcing
most programmers will skip them.

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


ethan at stoneleaf

Apr 4, 2012, 12:52 PM

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

Oleg Broytman wrote:
> On Wed, Apr 04, 2012 at 11:03:02AM -0700, Ethan Furman wrote:
>> Oleg Broytman wrote:
>>> . 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')
>>
>> Wow -- you'd rather write nine lines of code instead of three?
>>
>> clock = get_clock(THIS) or get_clock(THAT)
>> if clock is None:
>> raise ValueError('Cannot get clock, tried THIS and THAT')
>
> Yes - to force people to write the last two lines. Without forcing
> most programmers will skip them.

Forced? I do not use Python to be forced to use one style of
programming over another.

And it's not like returning None will allow some clock calls to work but
not others -- as soon as they try to use it, it will raise an exception.

~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 4, 2012, 3:06 PM

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

On 04Apr2012 19:47, Georg Brandl <g.brandl [at] gmx> wrote:
| 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.

And neither is get_clock() returning None. get_clock() is an inquiry
function, and None is a legitimate response when no clock is
satisfactory, just as a dict has no key for a get().

Conversely, monotonic() ("gimme the time!") and indeed time() should
raise an exception if there is no clock. They're, for want of a word,
"live" functions you would routinely embed in a calculation.

So not so much a straw man as a relevant illuminating example.
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

A crash reduces
your expensive computer
to a simple stone.
- Haiku Error Messages http://www.salonmagazine.com/21st/chal/1998/02/10chal2.html
_______________________________________________
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


steve at pearwood

Apr 4, 2012, 3:50 PM

Post #31 of 51 (280 views)
Permalink
Re: an alternative to embedding policy in PEP 418 [In reply to]

Oleg Broytman wrote:
> On Wed, Apr 04, 2012 at 11:03:02AM -0700, Ethan Furman wrote:
>> Oleg Broytman wrote:
>>> . 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')
>>
>> Wow -- you'd rather write nine lines of code instead of three?
>>
>> clock = get_clock(THIS) or get_clock(THAT)
>> if clock is None:
>> raise ValueError('Cannot get clock, tried THIS and THAT')
>
> Yes - to force people to write the last two lines. Without forcing
> most programmers will skip them.

You're not my real Dad! You can't tell me what to do!

*wink*

This level of paternalism is unnecessary. It's not your job to "force"
programmers to do anything. If people skip the test for None, they will get an
exception as soon as they try to use None as an exception, and then they will
fix their broken code.

Although I don't like the get_clock() API, I don't think this argument against
it is a good one. Exceptions are the *usual* error-handling mechanism in
Python, but they are not the *only* mechanism, there are others, and it is
perfectly okay to use non-exception based failures when appropriate. This is
one such example.

"Return None on failure" is how re.match() and re.search() work, and it is a
good design for when you have multiple fallbacks on failure.

result = re.match(spam, s) or re.match(ham, s) or re.match(eggs, s)
if result is None:
raise ValueError('could not find spam, ham or eggs')


This is a *much* better design than nested tries:

try:
result = re.match(spam, s)
except ValueError:
try:
result = re.match(ham, s)
except ValueError:
try:
result = re.match(eggs, s)
except ValueError:
raise ValueError('could not find spam, ham or eggs')


Wow. Now *that* is ugly code. There's nothing elegant or Pythonic about being
forced to write that out of a misplaced sense of purity.


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


phd at phdru

Apr 4, 2012, 4:05 PM

Post #32 of 51 (281 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 12:52:00PM -0700, Ethan Furman wrote:
> Oleg Broytman wrote:
> >On Wed, Apr 04, 2012 at 11:03:02AM -0700, Ethan Furman wrote:
> >>Oleg Broytman wrote:
> >>> . 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')
> >>
> >>Wow -- you'd rather write nine lines of code instead of three?
> >>
> >>clock = get_clock(THIS) or get_clock(THAT)
> >>if clock is None:
> >> raise ValueError('Cannot get clock, tried THIS and THAT')
> >
> > Yes - to force people to write the last two lines. Without forcing
> >most programmers will skip them.
>
> Forced? I do not use Python to be forced to use one style of
> programming over another.

Then it's strange you are using Python with its strict syntax
(case-sensitivity, forced indents), ubiquitous exceptions, limited
syntax of lambdas and absence of code blocks (read - forced functions),
etc.

> And it's not like returning None will allow some clock calls to work
> but not others -- as soon as they try to use it, it will raise an
> exception.

There is a philosophical distinction between EAFP and LBYL. I am
mostly proponent of LBYL.
Well, I am partially retreat. "Errors should never pass silently.
Unless explicitly silenced." get_clock(FLAG, on_error=None) could return
None.

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


cs at zip

Apr 4, 2012, 4:14 PM

Post #33 of 51 (278 views)
Permalink
Re: an alternative to embedding policy in PEP 418 [In reply to]

On 05Apr2012 08:50, Steven D'Aprano <steve [at] pearwood> wrote:
| Although I don't like the get_clock() API, I don't think this argument against
| it is a good one.

Just to divert briefly; you said in another post you didn't like the API
and (also/because?) it didn't help discoverability.

My core objective was to allow users to query for clocks, and ideally
enumerate and inspect all clocks. Without the caller having platform
specific knowledge.

Allowing for the sake of discussion that this is desirable, what would
you propose as an API instead of get_clock() (and its friend, get_clocks()
for enumeration, that I should stuff into the code).

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

Q: How many user support people does it take to change a light bulb?
A: We have an exact copy of the light bulb here and it seems to be
working fine. Can you tell me what kind of system you have?
_______________________________________________
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


stephen at xemacs

Apr 5, 2012, 6:06 AM

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

On Thu, Apr 5, 2012 at 8:05 AM, Oleg Broytman <phd [at] phdru> wrote:
> Well, I am partially retreat. "Errors should never pass silently.
> Unless explicitly silenced." get_clock(FLAG, on_error=None) could return
> None.

I still don't see what's erroneous about returning None when asked for
an object that is documented to possibly not exist, ever, in some
implementations. Isn't that precisely why None exists?
_______________________________________________
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 5, 2012, 6:34 AM

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

On Thu, Apr 05, 2012 at 10:06:38PM +0900, Stephen J. Turnbull wrote:
> On Thu, Apr 5, 2012 at 8:05 AM, Oleg Broytman <phd [at] phdru> wrote:
> > Well, I am partially retreat. "Errors should never pass silently.
> > Unless explicitly silenced." get_clock(FLAG, on_error=None) could return
> > None.
>
> I still don't see what's erroneous about returning None when asked for
> an object that is documented to possibly not exist, ever, in some
> implementations. Isn't that precisely why None exists?

Why doesn't open() return None for a non-existing file? or
socket.gethostbyname() for a non-existing name?

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


stephen at xemacs

Apr 5, 2012, 7:45 AM

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

On Thu, Apr 5, 2012 at 10:34 PM, Oleg Broytman <phd [at] phdru> wrote:

> Why doesn't open() return None for a non-existing file? or
> socket.gethostbyname() for a non-existing name?

That's not an answer to my question, because those calls have very
important use cases where the user knows the object exists (and in
fact in some cases open() will create it for him), so that failure to
exist is indeed a (user) error (such as a misspelling). I find it
hard to imagine use cases where "file = open(thisfile) or
open(thatfile)" makes sense. Not even for the case where thisfile ==
'script.pyc' and thatfile == 'script.py'.

The point of the proposed get_clock(), OTOH, is to ask if an object
with certain characteristics exists, and the fact that it returns the
clock rather than True if found is a matter of practical convenience.
Precisely because "clock = get_clock(best) or get_clock(better) or
get_clock(acceptable)" does make sense.
_______________________________________________
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 5, 2012, 8:22 AM

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

On Thu, Apr 05, 2012 at 11:45:06PM +0900, Stephen J. Turnbull wrote:
> On Thu, Apr 5, 2012 at 10:34 PM, Oleg Broytman <phd [at] phdru> wrote:
> > Why doesn't open() return None for a non-existing file? or
> > socket.gethostbyname() for a non-existing name?
>
> That's not an answer to my question, because those calls have very
> important use cases where the user knows the object exists (and in
> fact in some cases open() will create it for him), so that failure to
> exist is indeed a (user) error (such as a misspelling). I find it
> hard to imagine use cases where "file = open(thisfile) or
> open(thatfile)" makes sense. Not even for the case where thisfile ==
> 'script.pyc' and thatfile == 'script.py'.

Counterexamples - any configuration file: a program looks for its config
at $HOME and not finding it there looks in /etc. So
config = open('~/.someprogram.config') or open('/etc/someprogram/config')
would make sense. The absence of any of these files is not an error at
all - the program just starts with default configuration. So if the
resulting config in the code above would be None - it's still would be
ok. But Python doesn't allow that.
Some configuration files are constructed by combining a number of
user-defined and system-defined files. E.g., the mailcap database. It
should be something like
combined_database = [.db for db in (
open('/etc/mailcap'),
open('/usr/etc/mailcap'),
open('/usr/local/etc/mailcap'),
open('~/.mailcap'),
) if db]
But no way - open() raises IOError, not return None. And I think it is
the right way. Those who want to write the code similar to the examples
above - explicitly suppress exceptions by writing wrappers.

> The point of the proposed get_clock(), OTOH, is to ask if an object
> with certain characteristics exists, and the fact that it returns the
> clock rather than True if found is a matter of practical convenience.
> Precisely because "clock = get_clock(best) or get_clock(better) or
> get_clock(acceptable)" does make sense.

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


rdmurray at bitdance

Apr 5, 2012, 8:38 AM

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

On Thu, 05 Apr 2012 19:22:17 +0400, Oleg Broytman <phd [at] phdru> wrote:
> On Thu, Apr 05, 2012 at 11:45:06PM +0900, Stephen J. Turnbull wrote:
> > On Thu, Apr 5, 2012 at 10:34 PM, Oleg Broytman <phd [at] phdru> wrote:
> > >   Why doesn't open() return None for a non-existing file? or
> > > socket.gethostbyname() for a non-existing name?
> >
> > That's not an answer to my question, because those calls have very
> > important use cases where the user knows the object exists (and in
> > fact in some cases open() will create it for him), so that failure to
> > exist is indeed a (user) error (such as a misspelling). I find it
> > hard to imagine use cases where "file = open(thisfile) or
> > open(thatfile)" makes sense. Not even for the case where thisfile ==
> > 'script.pyc' and thatfile == 'script.py'.
>
> Counterexamples - any configuration file: a program looks for its config
> at $HOME and not finding it there looks in /etc. So
> config = open('~/.someprogram.config') or open('/etc/someprogram/config')
> would make sense. The absence of any of these files is not an error at
> all - the program just starts with default configuration. So if the
> resulting config in the code above would be None - it's still would be
> ok. But Python doesn't allow that.
> Some configuration files are constructed by combining a number of
> user-defined and system-defined files. E.g., the mailcap database. It
> should be something like
> combined_database = [.db for db in (
> open('/etc/mailcap'),
> open('/usr/etc/mailcap'),
> open('/usr/local/etc/mailcap'),
> open('~/.mailcap'),
> ) if db]
> But no way - open() raises IOError, not return None. And I think it is
> the right way. Those who want to write the code similar to the examples
> above - explicitly suppress exceptions by writing wrappers.

Ah, but the actual code in the mimetypes module (whose list is even
longer) looks like this:

for file in files:
if os.path.isfile(file):
db.read(file)

That is, Python provides a query function that doesn't raise an error.

Do you really think we need to add a third clock function (the query
function) that just returns True or False? Maybe we do, if actually
creating the clock could raise an error even if exists, as is the case
for 'open'.

(But unless I'm confused none of this has anything to do with Victor's
PEP as currently proposed :)

--David


phd at phdru

Apr 5, 2012, 9:01 AM

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

On Thu, Apr 05, 2012 at 07:22:17PM +0400, Oleg Broytman wrote:
> On Thu, Apr 05, 2012 at 11:45:06PM +0900, Stephen J. Turnbull wrote:
> > find it
> > hard to imagine use cases where "file = open(thisfile) or
> > open(thatfile)" makes sense. Not even for the case where thisfile ==
> > 'script.pyc' and thatfile == 'script.py'.
>
> Counterexamples - any configuration file: a program looks for its config
> at $HOME and not finding it there looks in /etc. So
> config = open('~/.someprogram.config') or open('/etc/someprogram/config')
> would make sense.

A counterexample with gethostbyname - a list of proxies. It's not an
error if some or even all proxies in the list are down - one just
connect to the first that's up. So a chain like
proxy_addr = gethostbyname(FIRST) or gethostbyname(SECOND)
would make sense.

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


phd at phdru

Apr 5, 2012, 9:02 AM

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

On Thu, Apr 05, 2012 at 11:38:13AM -0400, R. David Murray wrote:
> Do you really think we need to add a third clock function (the query
> function) that just returns True or False? Maybe we do, if actually
> creating the clock could raise an error even if exists, as is the case
> for 'open'.

May be we do. Depends on the usage patterns.

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


ethan at stoneleaf

Apr 5, 2012, 11:56 AM

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

Oleg Broytman wrote:
> On Wed, Apr 04, 2012 at 12:52:00PM -0700, Ethan Furman wrote:
>> Forced? I do not use Python to be forced to use one style of
>> programming over another.
>
> Then it's strange you are using Python with its strict syntax
> (case-sensitivity, forced indents), ubiquitous exceptions, limited
> syntax of lambdas and absence of code blocks (read - forced functions),
> etc.

I come from assembly -- 'a' and 'A' are *not* the same.

indents -- I already used them; finding a language that gave them the
same importance I did was incredible.

exceptions -- Python uses them, true, but I don't have to in my own code
(I do, but that's besides the point).

lambdas -- they work just fine for my needs.

etc.


>> And it's not like returning None will allow some clock calls to work
>> but not others -- as soon as they try to use it, it will raise an
>> exception.
>
> There is a philosophical distinction between EAFP and LBYL. I am
> mostly proponent of LBYL.
> Well, I am partially retreat. "Errors should never pass silently.
> Unless explicitly silenced." get_clock(FLAG, on_error=None) could return
> None.

It's only an error if it's documented that way and, more importantly,
thought of that way. The re module is a good example: if it can't find
what you're looking for it returns None -- it does *not* raise a
NotFound exception.

I see get_clock() the same way: I need a clock that does xyz... None?
Okay, there isn't one.

~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 5, 2012, 1:15 PM

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

On Thu, Apr 05, 2012 at 11:56:00AM -0700, Ethan Furman wrote:
> It's only an error if it's documented that way and, more
> importantly, thought of that way. The re module is a good example:
> if it can't find what you're looking for it returns None -- it does
> *not* raise a NotFound exception.

But open() raises IOError. ''.find('a') returns -1 but ''.index('a')
raises ValueError.
So we can argue in circles both ways, there are too many arguments
pro and contra. Python is just too inconsistent to be consistently
argued over. ;-)

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


ethan at stoneleaf

Apr 5, 2012, 1:49 PM

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

Oleg Broytman wrote:
> On Thu, Apr 05, 2012 at 11:56:00AM -0700, Ethan Furman wrote:
>> It's only an error if it's documented that way and, more
>> importantly, thought of that way. The re module is a good example:
>> if it can't find what you're looking for it returns None -- it does
>> *not* raise a NotFound exception.
>
> But open() raises IOError. ''.find('a') returns -1 but ''.index('a')
> raises ValueError.
> So we can argue in circles both ways, there are too many arguments
> pro and contra. Python is just too inconsistent to be consistently
> argued over. ;-)

Indeed -- I think we have reached an agreement! Now if you'll just
agree that returning None in this case is better... ;)

~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 5, 2012, 3:05 PM

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

On 05Apr2012 03:05, Oleg Broytman <phd [at] phdru> wrote:
| On Wed, Apr 04, 2012 at 12:52:00PM -0700, Ethan Furman wrote:
| > Forced? I do not use Python to be forced to use one style of
| > programming over another.
|
| Then it's strange you are using Python with its strict syntax
| (case-sensitivity, forced indents), ubiquitous exceptions, limited
| syntax of lambdas and absence of code blocks (read - forced functions),
| etc.

But exceptions are NOT ubiquitous, nor should they be. They're a very
popular and often apt way to handle certain circumstances, that's all.
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

On the one hand I knew that programs could have a compelling and deep logical
beauty, on the other hand I was forced to admit that most programs are
presented in a way fit for mechanical execution, but even if of any beauty at
all, totally unfit for human appreciation. - Edsger W. Dijkstra
_______________________________________________
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 5, 2012, 3:08 PM

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

On 06Apr2012 00:15, Oleg Broytman <phd [at] phdru> wrote:
| So we can argue in circles both ways, there are too many arguments
| pro and contra. Python is just too inconsistent to be consistently
| argued over. ;-)

Bah! I think these threads demonstrate that we can consistently argue
over Python for weeks per topic, sometimes months and years.
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

Sam Jones <samjones [at] leo> on the Nine Types of User:

Frying Pan/Fire Tactician - "It didn't work with the data set we had, so I
fed in my aunt's recipe for key lime pie."
Advantages: Will usually fix error.
Disadvantages: 'Fix' is defined VERY loosely here.
Symptoms: A tendancy to delete lines that get errors instead of fixing
them.
Real Case: One user complained that their program executed, but didn't
do anything. The scon looked at it for twenty minutes before
realizing that they'd commented out EVERY LINE. The user
said, "Well, that was the only way I could get it to compile."
_______________________________________________
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


stephen at xemacs

Apr 5, 2012, 7:57 PM

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

On Fri, Apr 6, 2012 at 12:22 AM, Oleg Broytman <phd [at] phdru> wrote:
> On Thu, Apr 05, 2012 at 11:45:06PM +0900, Stephen J. Turnbull wrote:
>> On Thu, Apr 5, 2012 at 10:34 PM, Oleg Broytman <phd [at] phdru> wrote:
>> > Why doesn't open() return None for a non-existing file? or
>> > socket.gethostbyname() for a non-existing name?
>>
>> That's not an answer to my question, because those calls have very
>> important use cases

Note, implicit existential quantifier.

> Counterexamples

Not an argument against an existential quantifier.

> But Python doesn't allow [.use of conditional constructs when opening a series of files, one must trap exceptions].

True. Python needs to make a choice, and the existence of important
cases where the user knows that the object (file) exists makes it
plausible that the user would prefer an Exception. Also, open() is
intended to be a fairly thin wrapper over the OS facility, and often
the OS terms a missing file an "error".

I might have chosen to implement a 'None' return if I had designed
open(), but I can't get too upset about raising an Exception as it
actually does.

What I want to know is why you're willing to assert that absence of a
clock of a particular configuration is an Exception, when that absence
clearly documented to be a common case? I don't find your analogies
to be plausible. They seem to come down to "sometimes in Python we've
made choices that impose extra work on some use cases, so we should
impose extra work on this use case too." But that surely isn't what
you mean.
_______________________________________________
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


steve at pearwood

Apr 6, 2012, 3:25 AM

Post #47 of 51 (264 views)
Permalink
Re: an alternative to embedding policy in PEP 418 [In reply to]

Cameron Simpson wrote:
> On 05Apr2012 08:50, Steven D'Aprano <steve [at] pearwood> wrote:
> | Although I don't like the get_clock() API, I don't think this argument against
> | it is a good one.
>
> Just to divert briefly; you said in another post you didn't like the API
> and (also/because?) it didn't help discoverability.
>
> My core objective was to allow users to query for clocks, and ideally
> enumerate and inspect all clocks. Without the caller having platform
> specific knowledge.

Clocks *are* platform specific -- not just in their availability, but also in
the fine details of their semantics and behaviour. I don't think we can or
should try to gloss over this. If people are making decisions about timers
without knowledge of what their platform supports, they're probably making
poor decisions. Even the venerable time.time() and time.clock() differ between
Linux and Windows.


> Allowing for the sake of discussion that this is desirable, what would
> you propose as an API instead of get_clock() (and its friend, get_clocks()
> for enumeration, that I should stuff into the code).

The old ways are the best. We don't have math.get_trig() and math.get_trigs()
functions for querying trigonometric functions, we just expose the functions
directly.

I think the way to enumerate and inspect all clocks is with the tried and true
Python introspection tools that people use on all other functions:

* use dir(time) to see a list of names available in the module
* use help(time) to read their help
* read the Fine Manual to find out more
* use try... except... to detect the existence of a clock

There's nothing special about clocks that needs anything more than this.

get_clock() looks like a factory function, but it actually isn't. It just
selects from a small number of pre-existing clocks. We should just expose
those pre-existing clocks directly. I don't see any advantage in adding that
extra level of indirection or the addition of all this complexity:

* a function get_clock() to select a clock
* a function get_clocks() to enumerate all the clocks
* another function for querying the properties of a clock

All those functions accomplish is to increase the complexity of the API, the
documentation and the implementation. It's one more special case for the user
to learn:

"To find out what functions are available, use dir(module), except for clocks,
where you have to use time.get_clocks()."

Blah.

Another problem with get_clock() -- it will be an attractive nuisance for the
sort of person who cares about symmetry and completeness. You will have a
steady trickle of "feature requests" from users who are surprised that not
every combination of features is supported. Out of the eight or sixteen or
thirty-two potential clocks that get_clock() tempts the user with, only three
or five will actually exist.

The only advantage of get_clock is that you don't need to know the *name* of a
platform clock in order to use it, you can describe it with a series of flags
or enums. But in practice, that's not an advantage, that's actually a
disadvantage. Consider:

"Which clock should I use for such-and-such a task, foo or bar?"

versus

"Which clock should I use for such-and-such a task, get_clock(spam, eggs,
cheese) or get_clock(ham, eggs, truffles)?"

The mere mechanics of talking about these clocks will suffer because they
aren't named.



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


murman at gmail

Apr 6, 2012, 4:31 AM

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

On Thu, Apr 5, 2012 at 21:57, Stephen J. Turnbull <stephen [at] xemacs> wrote:
> I might have chosen to implement a 'None' return if I had designed
> open(), but I can't get too upset about raising an Exception as it
> actually does.

One fundamental difference is that there are many reasons one might
fail to open a file. It may not exist. It may not have permissions
allowing the request. It may be locked. If open() returned None, this
information would have to be retrievable through another function.
However since it returns an exception, that information is already
wrapped up in the exception object, should you choose to catch it, and
likely to be logged otherwise.

In the case of the clocks, I'm assuming the only reason you would fail
to get a clock is because it isn't provided by hardware and/or OS. You
don't have to worry about transient scenarios on multi-user systems
where another user has locked the clock. Thus the exception cannot
tell you anything more than None tells you. (Of course, if my
assumption is wrong, I'm not sure whether my reasoning still applies.)

--
Michael Urman
_______________________________________________
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 6, 2012, 4:11 PM

Post #49 of 51 (262 views)
Permalink
Re: an alternative to embedding policy in PEP 418 [In reply to]

On 06Apr2012 20:25, Steven D'Aprano <steve [at] pearwood> wrote:
| Cameron Simpson wrote:
| > My core objective was to allow users to query for clocks, and ideally
| > enumerate and inspect all clocks. Without the caller having platform
| > specific knowledge.
|
| Clocks *are* platform specific -- not just in their availability, but also in
| the fine details of their semantics and behaviour. I don't think we can or
| should try to gloss over this.

This is why get_clock() returns a clock object, which can have metadata
exposing such details. Up to and including the name of the platform specific
library/system-call at its core.

The issue with monotonic() on its own is that the guarentees in the doco
will have to be fairly loose. That prevents the user learning about
"fine details of their semantics and behaviour". Glossing over this
stuff is exactly what offering _only_ a few genericly characterised
clock names (monotonic() et al) does.

| If people are making decisions about timers
| without knowledge of what their platform supports, they're probably making
| poor decisions. Even the venerable time.time() and time.clock() differ between
| Linux and Windows.

time.clock() does, as (you?) clearly demonstrated elsewhere.

time.time()? (Aside from precision?)

| > Allowing for the sake of discussion that this is desirable, what would
| > you propose as an API instead of get_clock() (and its friend, get_clocks()
| > for enumeration, that I should stuff into the code).
|
| The old ways are the best. We don't have math.get_trig() and math.get_trigs()
| functions for querying trigonometric functions, we just expose the functions
| directly.
|
| I think the way to enumerate and inspect all clocks is with the tried and true
| Python introspection tools that people use on all other functions:
|
| * use dir(time) to see a list of names available in the module

So, they see "monotonic". Does that tell them much about fine details?

| * use help(time) to read their help

Useful only to humans, not programs.

| * read the Fine Manual to find out more

Useful only to humans, not programs.

| * use try... except... to detect the existence of a clock

Useful only for a fixed list of defined name. Works fine for monotonic,
highres, steady or whatever. And I would be ok with the module
presenting these only where available and concealing them otherwise,
thus raising AttributeError. Or ImportError ("from time import
monotonic").

| There's nothing special about clocks that needs anything more than this.

This I think is false. In fact, I think your own statement at the start
about glossing over fine details goes against this.

If I ask for a highres clock, I might well care _how_ precise it was.

If I ask for a steady clock, I might well care how large its slews were.

If I ask for a monotonic clock, I might well want to know if it tracks
wall clock time (even if by magic) or elapsed system run time (eg time
that stops increasing if the system is suspended, whereas wallclocks do
not). Example: a wallclock is nice for log timestamps. A system run time
clock is nice for profiling. They're both monotonic in some domain.

| get_clock() looks like a factory function, but it actually isn't. It just
| selects from a small number of pre-existing clocks.

That number may still be a few. Victor's made it clear that Windows
has a choice of possible highres clocks, UNIX clock_getres() offers
several possible clock behaviours and an indication that a platform may
have several clocks embodying a subset of these, and may indeed offer
more clocks.

| We should just expose
| those pre-existing clocks directly.

But exposing them _purely_ _by_ _name_ means inventing names for every single
platform clock, and knowing those names per platform. time.clock() is a
fine example where the name tells you nearly nothing about the clock
behaviour. If the user cares about fine detail as you suggest they need
to know their platform and have _external_ knowledge of the platform
specifics; they can't inspect from inside the program.

| I don't see any advantage in adding that
| extra level of indirection or the addition of all this complexity:
| * a function get_clock() to select a clock
| * a function get_clocks() to enumerate all the clocks

These are only two functions because the next alternative seemed an
all_clocks= mode parameter, which changed the signature of the function
return.

Another alternative is the public lists-of-clocks.

The point it to be able to enumerate all available clocks for
consideration of their properties; get_clock() provides a simple way
to coarsely say "a clock like _this_" for the common instances of
"this".

| * another function for querying the properties of a clock

No, that's why you get a clock object back. You can examine it directly
for defined metadata names (epoch, precision, underlying-os-clock-name,
etc). In exactly the fashion you appear to want for the top level
offerings: by knowing the metadata property names.

| All those functions accomplish is to increase the complexity of the API, the
| documentation and the implementation. It's one more special case for the user
| to learn:
|
| "To find out what functions are available, use dir(module), except for clocks,
| where you have to use time.get_clocks()."

But dir(module) _will_ list monotonic et al anyway, and possibly matching
public clock list names. get_clock() is only for when you want to dig
around more flexibly.

| Another problem with get_clock() -- it will be an attractive nuisance for the
| sort of person who cares about symmetry and completeness. You will have a
| steady trickle of "feature requests" from users who are surprised that not
| every combination of features is supported. Out of the eight or sixteen or
| thirty-two potential clocks that get_clock() tempts the user with, only three
| or five will actually exist.

And the optional "clocklist" parameter addresses such feaping creaturism
by providing a hook for _other_ modules to offer a clock list. Such as a
list of syntheic clocks with cool (or insane:-) properties. Without
burdening the time module.

| The only advantage of get_clock is that you don't need to know the *name* of a
| platform clock in order to use it, you can describe it with a series of flags
| or enums. But in practice, that's not an advantage, that's actually a
| disadvantage. Consider:
|
| "Which clock should I use for such-and-such a task, foo or bar?"

What's your list of foo, bah? Again, I'm not talking about removing
monotonic et al. I'm talking about exposing the alternatives for when
the chosen-by-the-module monotonic doesn't fit.

| versus
| "Which clock should I use for such-and-such a task, get_clock(spam, eggs,
| cheese) or get_clock(ham, eggs, truffles)?"

One hopes the user knows the task. Then they can specify cheese or
truffles. Again, only if they feel they need to because the bare
monotonic et al don't fit, or was too vague.

| The mere mechanics of talking about these clocks will suffer because they
| aren't named.

But they _can_ be named! get_clock() is for when you don't know or care
their names, only their behaviours! And also for when an available clock
_wasn't_ one returned by the monotonic et al names.

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

I do not trust thee, Cage from Hell, / The reason why I cannot tell, /
But this I know, and know full well: / I do not trust thee, Cage from Hell.
- Leigh Ann Hussey, leighann [at] sybase, DoD#5913
_______________________________________________
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


v+python at g

Apr 6, 2012, 5:30 PM

Post #50 of 51 (257 views)
Permalink
Re: an alternative to embedding policy in PEP 418 [In reply to]

On 4/6/2012 4:11 PM, Cameron Simpson wrote:
> Another alternative is the public lists-of-clocks.

After watching this thread with amusement and frustration, amusement
because it is so big, and so many people have so many different
opinions, frustration, because it seems that few of the clocks that are
available are anywhere near ideal for any particular stated
characteristic, and because none of the APIs presented provide a way for
the user to specify the details of the characteristics of the desired
clock, I think this idea of a list-of-clocks sounds better and better.

Hopefully, for each system, the characteristics of each clock can be
discovered, and fully characterized in available metadata for the clock...

tick rate, or list of tick rates
maximum variation of tick rate
precision
maximum "helicopter drop" jump delta
monotonicity
frequency of rollover or None
base epoch value or None
behavior during system sleep, hibernate, suspend, shutdown, battery
failure, flood, wartime events, and acts of God. These last two may have
values that are long prose texts full of political or religious
rhetoric, such as the content of this thread :)
any other characteristics I forgot to mention

Of course, it is not clear that all of these characteristics can be
determined based on OS/Version; hardware vendors may have different
implementations.

There should be a way to add new clock objects to the list, given a set
of characteristics, and an API to retrieve them, at least by installing
a submodule that provides access to an additional clock.


cs at zip

Apr 6, 2012, 9:22 PM

Post #51 of 51 (60 views)
Permalink
Re: an alternative to embedding policy in PEP 418 [In reply to]

On 06Apr2012 17:30, Glenn Linderman <v+python [at] g> wrote:
| On 4/6/2012 4:11 PM, Cameron Simpson wrote:
| > Another alternative is the public lists-of-clocks.
|
| After watching this thread with amusement and frustration, amusement
| because it is so big, and so many people have so many different
| opinions, frustration, because it seems that few of the clocks that are
| available are anywhere near ideal for any particular stated
| characteristic,

My partner has occasionally opined that most Prolog programs simply
result in "*** NO ***". We could optimise for that and simplify the
implementation enormously. It would also let us provide very strong
guarrentees about the offered clocks on the basis that no suitable clock
would ever provided:-)

| and because none of the APIs presented provide a way for
| the user to specify the details of the characteristics of the desired
| clock, I think this idea of a list-of-clocks sounds better and better.
|
| Hopefully, for each system, the characteristics of each clock can be
| discovered, and fully characterized in available metadata for the clock...

Victor has asked me to do that for my skeleton, based on the tables he
has assembled. I'll see what i can do there...

| Of course, it is not clear that all of these characteristics can be
| determined based on OS/Version; hardware vendors may have different
| implementations.

If you can look up the kernel revision you can do fairly well. In
principle.

| There should be a way to add new clock objects to the list, given a set
| of characteristics, and an API to retrieve them, at least by installing
| a submodule that provides access to an additional clock.

Returning to seriousness, the get_clock() call admits a clocklist.
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

Principles have no real force except when one is well fed. - Mark Twain
_______________________________________________
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

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.