Mailing List Archive: Python: Dev

Re: an alternative to embedding policy in PEP 418

Index | Next | Previous | View Threaded

v+python at g

Apr 2, 2012, 10:44 AM

Post #1 of 24 (270 views)
Permalink

Re: an alternative to embedding policy in PEP 418

On 4/2/2012 4:37 AM, Victor Stinner wrote:
> 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.

If there are more than two clocks, with different characteristics, no
API is going to be both simple to use and fast to call.

If there are more than two clocks, with different characteristics, then
having an API to get the right API to call to get a time seems very
natural to me.

One thing I don't like about the idea of fallback being buried under
some API is that the efficiency of that API on each call must be less
than the efficiency of directly calling an API to get a single clock's
time. For frequently called high resolution clocks, this is more
burdensome than infrequently called clocks.... yet those seem to be the
ones for which fallbacks are proposed, because of potential unavailability.

Having properties on each of various different clock functions is
cumbersome... the user code must know about each clock, how to obtain
the properties, and then how to choose one for use... And how will one
be chosen for use? Under the assumption that all return some sort of
timestamp and take no parameters, a local name will be assigned to the
clock of interest:

if ...:
myTime = os.monotonous
elif ...:
myTime = os.evenhigherres
...
elif ...:
myTime = time. time

so that myTime can be use throughout. Cameron's API hides all the names
of the clocks, and instead offers to do the conditional logic for you,
and the resultant API returned can be directly assigned to myTime, and
the logic for choosing a clock deals only with the properties of the
clock, not the names of the APIs, which is a nice abstraction. There
would not even be a need to document the actual names of the APIs for
each individual clock, except that probably some folks would want to
directly code them, especially if they are not interested in
cross-platform work.

The only thing I'm not so sure about: can the properties be described by
flags? Might it not be better to have an API that allows specification
of minimum resolution, in terms of fractional seconds? Perhaps other
properties suffice as flags, but perhaps not resolution.

ncoghlan at gmail

Apr 2, 2012, 2:40 PM

Post #2 of 24 (261 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

On Tue, Apr 3, 2012 at 3:44 AM, Glenn Linderman <v+python [at] g> wrote:
> One thing I don't like about the idea of fallback being buried under some
> API is that the efficiency of that API on each call must be less than the
> efficiency of directly calling an API to get a single clock's time.

No, that's a misunderstanding of the fallback mechanism. The fallback
happens when the time module is initialised, not on every call. Once
the appropriate clock has been selected during module initialisation,
it is invoked directly at call time.

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

v+python at g

Apr 2, 2012, 2:59 PM

Post #3 of 24 (260 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

On 4/2/2012 2:40 PM, Nick Coghlan wrote:
> On Tue, Apr 3, 2012 at 3:44 AM, Glenn Linderman<v+python [at] g> wrote:
>> > One thing I don't like about the idea of fallback being buried under some
>> > API is that the efficiency of that API on each call must be less than the
>> > efficiency of directly calling an API to get a single clock's time.
> No, that's a misunderstanding of the fallback mechanism. The fallback
> happens when the time module is initialised, not on every call. Once
> the appropriate clock has been selected during module initialisation,
> it is invoked directly at call time.
Nick,

I would hope that is how the fallback mechanism would be coded, but I'm
pretty sure I've seen other comments in this thread that implied
otherwise. But please don't ask me to find them, this thread is huge.

Glenn

cs at zip

Apr 2, 2012, 3:03 PM

Post #4 of 24 (263 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

On 02Apr2012 10:44, Glenn Linderman <v+python [at] g> wrote:
| On 4/2/2012 4:37 AM, Victor Stinner wrote:
| > 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.
|
| If there are more than two clocks, with different characteristics, no
| API is going to be both simple to use and fast to call.
|
| If there are more than two clocks, with different characteristics, then
| having an API to get the right API to call to get a time seems very
| natural to me.

It is, though Victor's point about offering the very easy to use API is
valid. The new code has the "flat" monotonic() et al calls as well.

| One thing I don't like about the idea of fallback being buried under
| some API is that the efficiency of that API on each call must be less
| than the efficiency of directly calling an API to get a single clock's
| time. For frequently called high resolution clocks, this is more
| burdensome than infrequently called clocks.... yet those seem to be the
| ones for which fallbacks are proposed, because of potential unavailability.

I hadn't thought about that, but it isn't actually a big deal. The
overhead isn't zero, but in order to always use the _same_ clock to
return hires() (for example) the library has to cache the clock lookup
anyway. Current clockutils.py skeleton here:

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

does so.

| The only thing I'm not so sure about: can the properties be described by
| flags? Might it not be better to have an API that allows specification
| of minimum resolution, in terms of fractional seconds? Perhaps other
| properties suffice as flags, but perhaps not resolution.

It sounds nice, but there are some difficulties.

Firstly, the (currently just 3) flags were chosen to map to the three
features sought (in various cobinations) for clocks. Once you start
requesting precision (a totally reasonable desire, BTW) you also want to
request degree of slew (since "steady" is a tunabe term) and so forth.
And what for clocks that have variable precision (I'm imaging here a
clock which really is a float, and for large times (in the far future)
can't return the sane resolution because of the size of a float.

The concern is valid though. I could imagine beefing up the clock object
metadata with .epoch (can be None!), precision (function of float width
versus clock return value epislon), epsilon (your fraction of a second
parameter). Of course, for some clocks any of these might be None.

Then the truly concerned user iterates over the available clocks
with the desired coarse flags, inspecting each closely for precision
or whatever. Easy enough to tweak get_clock() to take an optional
all_clocks=False parameter to return all matching clocks in an iterable
instead of (the first match or None). Or the user could reach directly
for one of the clock lists.

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

Craft, n. A fool's substitute for brains. - The Devil's Dictionary
_______________________________________________
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, 5:18 PM

Post #5 of 24 (258 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

On 02Apr2012 14:59, Glenn Linderman <v+python [at] g> wrote:
| On 4/2/2012 2:40 PM, Nick Coghlan wrote:
| > On Tue, Apr 3, 2012 at 3:44 AM, Glenn Linderman<v+python [at] g> wrote:
| >> > One thing I don't like about the idea of fallback being buried under some
| >> > API is that the efficiency of that API on each call must be less than the
| >> > efficiency of directly calling an API to get a single clock's time.
| > No, that's a misunderstanding of the fallback mechanism. The fallback
| > happens when the time module is initialised, not on every call. Once
| > the appropriate clock has been selected during module initialisation,
| > it is invoked directly at call time.
|
| I would hope that is how the fallback mechanism would be coded, but I'm
| pretty sure I've seen other comments in this thread that implied
| otherwise. But please don't ask me to find them, this thread is huge.

The idea of falling back to different clocks on the fly on different
calls got a bit of a rejection I thought. A recipe for clock
inconsitency whatever the failings of the current clock.

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

We need a taxonomy for 'printing-that-is-no-longer-printing.'
- overhead by WIRED at the Intelligent Printing conference Oct2006
_______________________________________________
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 3, 2012, 4:53 PM

Post #6 of 24 (253 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [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). 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.

That's a matter of opinion. I'm not particularly fond of this get_clock idea,
but of the two examples given, I much prefer the first of these:

get_clock(MONOTONIC|HIRES)
get_clock(monotonic=True, highres=True)

and not just because it is shorter. The API is crying out for enum arguments,
not a series of named flags.

But frankly I think this get_clock API sucks. At some earlier part of this
thread, somebody listed three or four potential characteristics of clocks. If
we offer these as parameters to get_clock(), that means there's eight or
sixteen different clocks that the user can potentially ask for. Do we really
offer sixteen different clocks? Or even eight? I doubt it -- there's probably
only two or three. So the majority of potential clocks don't exist.

With get_clock, discoverability is hurt. How does the caller know what clocks
are available? How can she look for documentation for them?

A simple, obvious, discoverable API is best. If we offer three clocks, we have
three named functions. If some of these clocks aren't available on some
platform, and we can't emulate them, then simply don't have that named
function available on that platform. That's easy to discover: trying to use
that clock will give a NameError or AttributeError, and the caller can then
fall back on an alternative, or fail, whichever is appropriate.

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

victor.stinner at gmail

Apr 3, 2012, 5:02 PM

Post #7 of 24 (255 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

> Lennart Regebro wrote:
>> Well, get_clock(monotonic=True, highres=True) would be a vast
>> improvement over get_clock(MONOTONIC|HIRES).

I don't like this keyword API because you have to use a magically
marker (True). Why True? What happens if I call
get_clock(monotonic=False) or get_clock(monotonic="yes")?

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

Post #8 of 24 (260 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

On 04Apr2012 09:53, Steven D'Aprano <steve [at] pearwood> 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).[...]
|
| That's a matter of opinion. I'm not particularly fond of this get_clock idea,
| but of the two examples given, I much prefer the first of these:
|
| get_clock(MONOTONIC|HIRES)
| get_clock(monotonic=True, highres=True)
|
| and not just because it is shorter. The API is crying out for enum arguments,
| not a series of named flags.

Enums would be ok with me. I went with a bitmask because it is natural
to me and very simple. But anything symbolicly expression will do.

| But frankly I think this get_clock API sucks. At some earlier part of this
| thread, somebody listed three or four potential characteristics of clocks. If
| we offer these as parameters to get_clock(), that means there's eight or
| sixteen different clocks that the user can potentially ask for. Do we really
| offer sixteen different clocks? Or even eight? I doubt it -- there's probably
| only two or three. So the majority of potential clocks don't exist.

That's not the point. I think we should offer all the platform system clocks,
suitably described. That there are up to 8 or 16 flag combinations is
irrelevant; no user is going to try them all. A user will have requirements
for their clock. They ask for them either blandly via get_clock() or (for
example considering monotonic most important) via monotonic_clock(). In the
latter case, the supported clocks can be considered in a more apt order via a
different internal clock list.

| With get_clock, discoverability is hurt.

No, because the other calls still exist. (In my proposal. I see Victor's
characterised this as either/or in the PEP, never my intent.)

| How does the caller know what clocks
| are available?

I would definitely want either:

- the module clock lists available via public names, for example as in
my sample clockutils.py code (ALL_CLOCKS, MONTONIC_CLOCKS etc) or
via some map (eg clocks['monotonic']).

- a get_clocks() function to return matching clocks, like get_clock()
but not stopping on the first match

- an all_clocks=False parameter to get_clock() to get an iterable of
the suitable clocks

| How can she look for documentation for them?

There is good text in the PEP. That could be easily moved into the
module doco in a "clocks" section. Since my clocks proposal wraps clocks
in an object, they _can_ have nice class names and good docstrings and
more metadata in the object (possibilities including .epoch, .precision,
.is_steady() methods, .os_clock_name (eg "QueryPerformanceCounter"), etc).

| A simple, obvious, discoverable API is best. If we offer three clocks, we have
| three named functions. If some of these clocks aren't available on some
| platform, and we can't emulate them, then simply don't have that named
| function available on that platform. That's easy to discover: trying to use
| that clock will give a NameError or AttributeError, and the caller can then
| fall back on an alternative, or fail, whichever is appropriate.

And I hate this. Because many platforms offer several OS clocks. The
time module SHOULD NOT dictate what clocks you get to play with, and you
should not need to have platform specific knowledge to look for a clock
with your desired characteristics.

If you just want montonic() and trust the module authors' policy
decisions you can go with monotonic(), have it do AttributeError if
unavailable and never worry about discoverability or the inspectable
object layer. Many will probaby be happy with that.

But without get_clock() or something like it, there is no
discoverability and not ability for a user to decide their own clock
choice policy.
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

Your modesty is typically human, so I will overlook it. - a Klingon
_______________________________________________
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

solipsis at pitrou

Apr 4, 2012, 2:46 AM

Post #9 of 24 (249 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

On Wed, 4 Apr 2012 02:02:12 +0200
Victor Stinner <victor.stinner [at] gmail> wrote:
> > Lennart Regebro wrote:
> >> Well, get_clock(monotonic=True, highres=True) would be a vast
> >> improvement over get_clock(MONOTONIC|HIRES).
>
> I don't like this keyword API because you have to use a magically
> marker (True). Why True? What happens if I call
> get_clock(monotonic=False) or get_clock(monotonic="yes")?

Since when are booleans magical? Has this thread gone totally insane?

Regards

Antoine.

_______________________________________________
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 4, 2012, 4:04 AM

Post #10 of 24 (245 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

2012/4/4 Antoine Pitrou <solipsis [at] pitrou>:
> On Wed, 4 Apr 2012 02:02:12 +0200
> Victor Stinner <victor.stinner [at] gmail> wrote:
>> > Lennart Regebro wrote:
>> >> Well, get_clock(monotonic=True, highres=True) would be a vast
>> >> improvement over get_clock(MONOTONIC|HIRES).
>>
>> I don't like this keyword API because you have to use a magically
>> marker (True). Why True? What happens if I call
>> get_clock(monotonic=False) or get_clock(monotonic="yes")?
>
> Since when are booleans magical? Has this thread gone totally insane?

It depends if the option supports other values. But as I understood,
the keyword value must always be True.

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

rosuav at gmail

Apr 4, 2012, 4:41 AM

Post #11 of 24 (248 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

On Wed, Apr 4, 2012 at 9:04 PM, Victor Stinner <victor.stinner [at] gmail> wrote:
> 2012/4/4 Antoine Pitrou <solipsis [at] pitrou>:
>> On Wed, 4 Apr 2012 02:02:12 +0200
>> Victor Stinner <victor.stinner [at] gmail> wrote:
>>> > Lennart Regebro wrote:
>>> >> Well, get_clock(monotonic=True, highres=True) would be a vast
>>> >> improvement over get_clock(MONOTONIC|HIRES).
>>>
>>> I don't like this keyword API because you have to use a magically
>>> marker (True). Why True? What happens if I call
>>> get_clock(monotonic=False) or get_clock(monotonic="yes")?
>>
>> Since when are booleans magical? Has this thread gone totally insane?
>
> It depends if the option supports other values. But as I understood,
> the keyword value must always be True.

If I were looking at that in documentation, my automatic guess would
be that the only thing that matters is whether the argument
compares-as-true or not. So get_clock(monotonic="yes") would be the
same as =True, and =False wouldn't be. And get_clock(monotonic="No,
you idiot, I want one that ISN'T") would... be stupid. But it'd still
function :)

Chris Angelico
_______________________________________________
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:44 AM

Post #12 of 24 (243 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

On Wed, Apr 4, 2012 at 13:04, Victor Stinner <victor.stinner [at] gmail> wrote:
> It depends if the option supports other values. But as I understood,
> the keyword value must always be True.

Or False, obviously. Which would also be default.

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

victor.stinner at gmail

Apr 4, 2012, 4:10 PM

Post #13 of 24 (243 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

2012/4/4 Lennart Regebro <regebro [at] gmail>:
> On Wed, Apr 4, 2012 at 13:04, Victor Stinner <victor.stinner [at] gmail> wrote:
>> It depends if the option supports other values. But as I understood,
>> the keyword value must always be True.
>
> Or False, obviously. Which would also be default.

Ok for the default, but what happens if the caller sets an option to
False? Does get_clock(monotonic=False) return a non-monotonic clock?
(I guess no, but it may be confusing.)

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

regebro at gmail

Apr 5, 2012, 1:21 AM

Post #14 of 24 (237 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

On Thu, Apr 5, 2012 at 01:10, Victor Stinner <victor.stinner [at] gmail> wrote:
> 2012/4/4 Lennart Regebro <regebro [at] gmail>:
>> On Wed, Apr 4, 2012 at 13:04, Victor Stinner <victor.stinner [at] gmail> wrote:
>>> It depends if the option supports other values. But as I understood,
>>> the keyword value must always be True.
>>
>> Or False, obviously. Which would also be default.
>
> Ok for the default, but what happens if the caller sets an option to
> False? Does get_clock(monotonic=False) return a non-monotonic clock?
> (I guess no, but it may be confusing.)

Good point, but the same does for using flags. If you don't pass in
the MONOTONIC flag, what happens? Only reading the documentation will
tell you. As such this, if anything, is an indication that the
get_clock() API isn't ideal in any incarnation.

//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 5, 2012, 3:17 PM

Post #15 of 24 (230 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

On 05Apr2012 10:21, Lennart Regebro <regebro [at] gmail> wrote:
| On Thu, Apr 5, 2012 at 01:10, Victor Stinner <victor.stinner [at] gmail> wrote:
| > Ok for the default, but what happens if the caller sets an option to
| > False? Does get_clock(monotonic=False) return a non-monotonic clock?
| > (I guess no, but it may be confusing.)

This is where the bitmap approach can be less confusing - the docstring
says "The returned clock shall have all the requested flags". It is at
least very predictable.

| Good point, but the same does for using flags.

Only notionally. With a keyword argument the (lazy non doc reading)
caller can imagine the default is None, and True and False specify
concrete position and negative requirements. Not the case with a
bitmask, which only has two states per feature, not three (or
arbitrarily many, depending how nasty one wants to be - I could play
devil's advocate and ask for monotonic=0.7 and demand a competivtive
evaluation of relative merits:-)

| If you don't pass in
| the MONOTONIC flag, what happens? Only reading the documentation will
| tell you.

Gah! ALL functions are like that! How often do we see questions about
max() or split() etc that a close reading of the docs obviate?

| As such this, if anything, is an indication that the
| get_clock() API isn't ideal in any incarnation.

It's not meant to be ideal. I find that word almost useless in its
overuse. get_clock() is meant to be _very_ _often_ _useful_ and easy to
use for expressing simple fallback when the PEP418 monotonic() et al
calls don't fit.

For the truly arbitrary case the caller needs to be able to enumerate
all the available clocks and make their own totally ad hoc decision. My
current example code offers both public lock list names and get_clocks()
(just like get_clock() in signature, but returning all matches instead
of just the first one).

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

>From the EXUP mailing list <exup-brotherhood [at] Majordomo> ...
Wayne Girdlestone <WayneG [at] mega>:
WG> Let's say there are no Yamaha's or Kawa's in the world.
Stevey Racer <ssturm [at] co>:
SR> sriw - so then you are saying that Revelations (from the Bible) has come
SR> true and Hell is now on Earth.
WG> Your choice for you new bike is either a new '98 fuel injected SRAD, or a
WG> new '98 Fireblade.
SR> sriw -The devil's minions - full of temptation but never fulfilling their
SR> promise.
_______________________________________________
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 5, 2012, 3:27 PM

Post #16 of 24 (234 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

Le 06/04/2012 00:17, Cameron Simpson a écrit :
> This is where the bitmap approach can be less confusing - the docstring
> says "The returned clock shall have all the requested flags". It is at
> least very predictable.

By the way, I removed ("deferred") the time.highres() function from the
PEP, and I try to avoid the term "steady" because no OS clock respect
the definition of "steady" (especially in corner cases as system
suspend/resume). So which flags do you want to support? (only "monotonic"?)

Basically, get_clock("monotonic") should give time.monotonic() whereas
get_clock() gives 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

cs at zip

Apr 5, 2012, 3:51 PM

Post #17 of 24 (231 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

On 06Apr2012 00:27, Victor Stinner <victor.stinner [at] gmail> wrote:
| Le 06/04/2012 00:17, Cameron Simpson a Ã©crit :
| > This is where the bitmap approach can be less confusing - the docstring
| > says "The returned clock shall have all the requested flags". It is at
| > least very predictable.
|
| By the way, I removed ("deferred") the time.highres() function from the
| PEP,

Chuckle; was not the whole PEP for a high res clock?

| and I try to avoid the term "steady" because no OS clock respect
| the definition of "steady" (especially in corner cases as system
| suspend/resume).

I can think of definitions of "steady" that I personally would accept,
and they'd accept that suspend/resume would be concealed (I guess I
would usually want - purely myself here - a clock representing system
run time; I'd go for time.time() for wall clock).

| So which flags do you want to support? (only "monotonic"?)

I'd stay with my current list, with metadata in the clock objects
indicating what _flavour_ of "steady" or "high res" they present.

| Basically, get_clock("monotonic") should give time.monotonic() whereas

If time.monotonic() never falls back to a non-monotonic source, yes.

| get_clock() gives time.time()?

Might in theory give something better, but time.time() would always be a
valid result of nothing else seemed better to the module author. I imagine
in practice that time.time() might always use the "best" clock absent
special requirements. So you'd probably get what particular clock used to
implement time.time(), yes. (I realise this has interesting implications
for the list orders; time.time() would come _first_, but providing feature
flags to get_clock() can cause it not to be chosen when it doesn't match.)

This a reason why I think we should present (even privately only) all the
system clocks for a platform. Then you _can_ still offer highres() and
steady() with detailed qualifications in the docs as to what
considerations went into acepting a clock as highres or steady, and
therefore why some users may find them unsatisfactory i.e. under what
sort of circumstances/requirements they may not suit.

Any of the montonic()/highres()/steady() represent policy decisions by
the module author; it is just that monotonic() is easier to qualify than
the others: "never goes backwards in return value". Even though VMs and
system suspend can add depth to the arguments.

It _is_ useful for people to be able to reach for highres() or steady()
a lot of the time; they do, though, need to be able to decide if that's
sensible.

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

I thought back to other headaches from my past and sneered at their
ineffectiveness. - Harry Harrison
_______________________________________________
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, 5:48 PM

Post #18 of 24 (229 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

On 06Apr2012 08:51, I wrote:
| On 06Apr2012 00:27, Victor Stinner <victor.stinner [at] gmail> wrote:
| | By the way, I removed ("deferred") the time.highres() function from the
| | PEP,
|
| Chuckle; was not the whole PEP for a high res clock?

Gah. I see it was for montonic, not high res. Sorry.

[...]
| I can think of definitions of "steady" that I personally would accept,
| and they'd accept that suspend/resume would be concealed (I guess I
| would usually want - purely myself here - a clock representing system
| run time; I'd go for time.time() for wall clock).
|
| | So which flags do you want to support? (only "monotonic"?)
|
| I'd stay with my current list, with metadata in the clock objects
| indicating what _flavour_ of "steady" or "high res" they present.

On reflection, since I have historically presumed time.time() on UNIX
mapped to "man 2 time", I clearly think that time.time() is wall clock
time, and may jump when the sysadmin notices it is incorrect (of course
this is often mediated by NTP, which in turn is usually mediated by
some ntpd using adjtime(), which slews instead of jumping). But it might
jump. (I'm intending to jump a wayard VM today, in fact:-)

So guess I expect time.time() to be only usually steady. And usually
monotonic. So having neither flag. Do I want a WALLCLOCK flag? Meaning a
clock that is supposed to be real world time (did I see REALTIME in one
of your examples?), and may be almost arbirarily corrected to be made
real world if it is wrong. Maybe. +0 on that I think.

Basicly I'm distinguishing here between a clock used for timestamps, for
example in log entries, and a clock used for measuring elapsed system
run time, for example in benchmarking. I would want to log entries to
match what a clock on the wall should say.

So I think I'm _still_ for the three original flags I suggested
(monotonic, high res, steady) and expect time.time() to not necessarily
meet any of them. But to meet a hypothetical WALLCLOCK flag.

Regarding UNIX time(2) (or POSIX time(3)), POSIX says:

The time() function shall return the value of time in seconds since
the Epoch.

and the epoch is a date. So UNIX time() should be a wall clock.
Python "help(time.time)" says:

Return the current time in seconds since the Epoch.

So I think it should also be a wall clock by that same reasoning.

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

Uh, this is only temporary...unless it works. - Red Green
_______________________________________________
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 6, 2012, 6:40 AM

Post #19 of 24 (229 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

On Fri, Apr 06, 2012 at 11:57:20AM +0900, "Stephen J. Turnbull" <stephen [at] xemacs> wrote:
> 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?

An error or not an error depends on how people will use the API. I
usually don't like error codes -- people tend to ignore them or check
lazily. If some library would do

(get_clock(THIS) or get_clock(THAT)).clock()

I want to get a clearly defined and documented clock-related error, not
some vague "AttributeError: 'NoneType' object has no attribute 'clock'".

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 6, 2012, 7:40 AM

Post #20 of 24 (227 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

Oleg Broytman wrote:
> On Fri, Apr 06, 2012 at 11:57:20AM +0900, "Stephen J. Turnbull" <stephen [at] xemacs> wrote:
>> 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?
>
> An error or not an error depends on how people will use the API. I
> usually don't like error codes -- people tend to ignore them or check
> lazily. If some library would do
>
> (get_clock(THIS) or get_clock(THAT)).clock()
>
> I want to get a clearly defined and documented clock-related error, not
> some vague "AttributeError: 'NoneType' object has no attribute 'clock'".

The error won't be that vague -- it will include that offending line,
making the problem easy to track.

~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

regebro at gmail

Apr 6, 2012, 2:05 PM

Post #21 of 24 (227 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

On Fri, Apr 6, 2012 at 00:17, Cameron Simpson <cs [at] zip> wrote:
> Gah! ALL functions are like that! How often do we see questions about
> max() or split() etc that a close reading of the docs obviate?

My point exactly.

//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 6, 2012, 2:26 PM

Post #22 of 24 (224 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

Lennart Regebro wrote:
> On Fri, Apr 6, 2012 at 00:17, Cameron Simpson <cs [at] zip> wrote:
>>
> Good point, but the same does for using flags. If you don't pass in
> the MONOTONIC flag, what happens? Only reading the documentation will
> tell you. As such this, if anything, is an indication that the
> get_clock() API isn't ideal in any incarnation.
>>
>> Gah! ALL functions are like that! How often do we see questions about
>> max() or split() etc that a close reading of the docs obviate?
>
> My point exactly.

Huh? Your point is that all APIs are less than ideal because you have
to read the docs to know for certain how they work?

~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

guido at python

Apr 6, 2012, 2:54 PM

Post #23 of 24 (223 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

I don't know who started this, but the PEP 418 threads have altogether
too much snarkiness and not enough content. It's bad enough that we're
bikeshedding so intensely; we don't need clever comebacks in
triplicate to every out-of-context argument.

--Guido

On Fri, Apr 6, 2012 at 2:26 PM, Ethan Furman <ethan [at] stoneleaf> wrote:
> Lennart Regebro wrote:
>>
>> On Fri, Apr 6, 2012 at 00:17, Cameron Simpson <cs [at] zip> wrote:
>>>
>>>
>> Good point, but the same does for using flags. If you don't pass in
>>
>> the MONOTONIC flag, what happens? Only reading the documentation will
>> tell you. As such this, if anything, is an indication that the
>>
>> get_clock() API isn't ideal in any incarnation.
>>>
>>>
>>> Gah! ALL functions are like that! How often do we see questions about
>>> max() or split() etc that a close reading of the docs obviate?
>>
>>
>> My point exactly.
>
>
> Huh? Your point is that all APIs are less than ideal because you have to
> read the docs to know for certain how they work?
>
> ~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/guido%40python.org

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
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 8, 2012, 6:29 PM

Post #24 of 24 (212 views)
Permalink

Re: an alternative to embedding policy in PEP 418 [In reply to]

On Fri, Apr 6, 2012 at 23:26, Ethan Furman <ethan [at] stoneleaf> wrote:
> Huh? Your point is that all APIs are less than ideal because you have to
> read the docs to know for certain how they work?

No.

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads