Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Lennart Regebro]

On Thu, Apr 5, 2012 at 00:45, Greg Ewing  wrote:
> Lennart Regebro wrote:
>>
>> Since the only monotonic clock that can be adjusted by NTP is Linux'
>> CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
>> give a clock that isn't adjusted by NTP.
>
> I thought we decided that NTP adjustment isn't an issue, because
> it's always gradual.

Well, in timings it is an issue, but perhaps not a big one. :-)
In any case, which one we use will not change the API, so if it is
decided it is an issue, we can always more to CLOCK_MONOTONIC_RAW in
the future, once Linux < 2.6.26 (or whatever it was) is deemed
unsupported.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418

[Lennart Regebro]

On Thu, Apr 5, 2012 at 01:10, Victor Stinner  wrote:
> 2012/4/4 Lennart Regebro :
>> On Wed, Apr 4, 2012 at 13:04, Victor Stinner  
>> wrote:
>>> It depends if the option supports other values. But as I understood,
>>> the keyword value must always be True.
>>
>> Or False, obviously. Which would also be default.
>
> Ok for the default, 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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Issue #3033: Add displayof parameter to tkinter font.

[Antoine Pitrou]

On Thu, 05 Apr 2012 11:41:48 +0200
andrew.svetlov  wrote:
> http://hg.python.org/cpython/rev/774c2afa6665
> changeset:   76115:774c2afa6665
> user:Andrew Svetlov 
> date:Thu Apr 05 12:41:20 2012 +0300
> summary:
>   Issue #3033: Add displayof parameter to tkinter font.
> Patch by Guilherme Polo.

Aren't there any docs?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Victor Stinner]

>>> Since the only monotonic clock that can be adjusted by NTP is Linux'
>>> CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
>>> give a clock that isn't adjusted by NTP.
>>
>> I thought we decided that NTP adjustment isn't an issue, because
>> it's always gradual.
>
> Well, in timings it is an issue, but perhaps not a big one. :-)
> In any case, which one we use will not change the API, so if it is
> decided it is an issue, we can always more to CLOCK_MONOTONIC_RAW in
> the future, once Linux < 2.6.26 (or whatever it was) is deemed
> unsupported.

I prefer to use CLOCK_MONOTONIC, not because it is also available for
older Linux kernels, but because it is more reliable. Even if the
underlying clock source is unstable (unstable frequency), a delta of
two reads of the CLOCK_MONOTONIC clock is a result in *seconds*,
whereas CLOCK_MONOTONIC_RAW may use an unit a little bit bigger or
smaller than a second. time.monotonic() unit is the second, as written
in its documentation.

Linux is the OS providing the most reliable monotonic clock, why
should you use a not reliable monotonic clock instead?

NTP doesn't step CLOCK_MONOTONIC, it only slew it.
http://www.python.org/dev/peps/pep-0418/#ntp-adjustment

Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Victor Stinner]

2012/4/5 PJ Eby :
>> More details why it's hard to define such function and why I dropped
>> it from the PEP.
>>
>> If someone wants to propose again such function ("monotonic or
>> fallback to system" clock), two issues should be solved:
>>
>>  - name of the function
>>  - description of the function
>
> Maybe I missed it, but did anyone ever give a reason why the fallback
> couldn't be to Steven D'Aprano's monotonic wrapper algorithm over the system
> clock?  (Given a suitable minimum delta.)  That function appeared to me to
> provide a sufficiently monotonic clock for timeout purposes, if nothing
> else.


Did you read the following section of the PEP?
http://www.python.org/dev/peps/pep-0418/#working-around-operating-system-bugs

Did I miss something? If yes, could you write a patch for the PEP please?

Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Issue #3033: Add displayof parameter to tkinter font.

[Andrew Svetlov]

Maybe you will be surprised, but tkinter.rst has no comprehensive docs
for any tkinter class.
I like to get it fixed but definitely cannot do it myself. My very
poor English is the main objection for writing narrative
documentation.

On Thu, Apr 5, 2012 at 1:21 PM, Antoine Pitrou  wrote:
> On Thu, 05 Apr 2012 11:41:48 +0200
> andrew.svetlov  wrote:
>> http://hg.python.org/cpython/rev/774c2afa6665
>> changeset:   76115:774c2afa6665
>> user:        Andrew Svetlov 
>> date:        Thu Apr 05 12:41:20 2012 +0300
>> summary:
>>   Issue #3033: Add displayof parameter to tkinter font.
>> Patch by Guilherme Polo.
>
> Aren't there any docs?
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com



-- 
Thanks,
Andrew Svetlov
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] FS: [issue9141] Allow objects to decide if they can be collected by GC

[Kristján Valur Jónsson]

Hi there. Antoine Pitrou suggested that I float this on python-dev again.  The 
new patch should
1) be much simpler and less hacky
2) remove the special case code for PyGenObject from gcmodule.c
K


Frá: Kristján Valur Jónsson [rep...@bugs.python.org]
Sent: 5. apríl 2012 11:55
To: Kristján Valur Jónsson
Efni: [issue9141] Allow objects to decide if they can be collected by GC

Kristján Valur Jónsson  added the comment:

Here is a completely new patch.  This approach uses the already existing 
tp_is_gc enquiry slot to signal garbage collection.
The patch modifies the generator object to use this new mechanism.
The patch keeps the old PyGen_NeedsFinalizing() API, but this can now go away, 
unless people think it might be used in extension modules

(why do we always expose all those internal apis from the dll? I wonder.)

--
Added file: http://bugs.python.org/file25131/ob_is_gc.patch

___
Python tracker 

___
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

[Stephen J. Turnbull]

On Thu, Apr 5, 2012 at 8:05 AM, Oleg Broytman  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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

[Oleg Broytman]

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  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 Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Issue #3033: Add displayof parameter to tkinter font.

[R. David Murray]

(reformatted to remove topposting)

On Thu, 05 Apr 2012 14:52:56 +0300, Andrew Svetlov  
wrote:
> On Thu, Apr 5, 2012 at 1:21 PM, Antoine Pitrou  wrote:
> > On Thu, 05 Apr 2012 11:41:48 +0200
> > andrew.svetlov  wrote:
> >> http://hg.python.org/cpython/rev/774c2afa6665
> >> changeset:   76115:774c2afa6665
> >> user:        Andrew Svetlov 
> >> date:        Thu Apr 05 12:41:20 2012 +0300
> >> summary:
> >>   Issue #3033: Add displayof parameter to tkinter font.
> >> Patch by Guilherme Polo.
> >
> > Aren't there any docs?
>
> Maybe you will be surprised, but tkinter.rst has no comprehensive docs
> for any tkinter class.
> I like to get it fixed but definitely cannot do it myself. My very
> poor English is the main objection for writing narrative
> documentation.

One way to approach this problem would be to draft some rough docs that
try to capture the functionality without worrying about English content
or style.  Then you could post the rough draft somewhere, and ask for
someone from the docs mailing list to edit it.  My thought would be that
whoever took on the task would then do a rewrite, asking you questions
to fill in any details that aren't clear from the rough draft.

Thank, you, by the way, for all the work you are doing.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Issue #3033: Add displayof parameter to tkinter font.

[Andrew Svetlov]

Thank you, David.
Is separate repo clone located at hg.python.org good enough? Or maybe
there are better way to do it?

On Thu, Apr 5, 2012 at 5:06 PM, R. David Murray  wrote:
> (reformatted to remove topposting)
>
> On Thu, 05 Apr 2012 14:52:56 +0300, Andrew Svetlov  
> wrote:
>> On Thu, Apr 5, 2012 at 1:21 PM, Antoine Pitrou  wrote:
>> > On Thu, 05 Apr 2012 11:41:48 +0200
>> > andrew.svetlov  wrote:
>> >> http://hg.python.org/cpython/rev/774c2afa6665
>> >> changeset:   76115:774c2afa6665
>> >> user:        Andrew Svetlov 
>> >> date:        Thu Apr 05 12:41:20 2012 +0300
>> >> summary:
>> >>   Issue #3033: Add displayof parameter to tkinter font.
>> >> Patch by Guilherme Polo.
>> >
>> > Aren't there any docs?
>>
>> Maybe you will be surprised, but tkinter.rst has no comprehensive docs
>> for any tkinter class.
>> I like to get it fixed but definitely cannot do it myself. My very
>> poor English is the main objection for writing narrative
>> documentation.
>
> One way to approach this problem would be to draft some rough docs that
> try to capture the functionality without worrying about English content
> or style.  Then you could post the rough draft somewhere, and ask for
> someone from the docs mailing list to edit it.  My thought would be that
> whoever took on the task would then do a rewrite, asking you questions
> to fill in any details that aren't clear from the rough draft.
>
> Thank, you, by the way, for all the work you are doing.
>
> --David
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com
>



-- 
Thanks,
Andrew Svetlov
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

[Stephen J. Turnbull]

On Thu, Apr 5, 2012 at 10:34 PM, Oleg Broytman  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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

[Oleg Broytman]

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  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 Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Issue #3033: Add displayof parameter to tkinter font.

[R. David Murray]

On Thu, 05 Apr 2012 17:34:07 +0300, Andrew Svetlov  
wrote:
> Thank you, David.
> Is separate repo clone located at hg.python.org good enough? Or maybe
> there are better way to do it?

That sounds like a good plan to me.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

[R. David Murray]

On Thu, 05 Apr 2012 19:22:17 +0400, Oleg Broytman  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  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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Ethan Furman]

Cameron Simpson wrote:

On 04Apr2012 22:23, PJ Eby  wrote:
| On Apr 4, 2012 7:28 PM, "Victor Stinner"  wrote:
| > More details why it's hard to define such function and why I dropped
| > it from the PEP.
| >
| > If someone wants to propose again such function ("monotonic or
| > fallback to system" clock), two issues should be solved:
| >
| >  - name of the function
| >  - description of the function
| 
| Maybe I missed it, but did anyone ever give a reason why the fallback

| couldn't be to Steven D'Aprano's monotonic wrapper algorithm over the
| system clock?  (Given a suitable minimum delta.)  That function appeared to
| me to provide a sufficiently monotonic clock for timeout purposes, if
| nothing else.

It was pointed out (by Nick Coglan I think?) that if the system clock
stepped backwards then a timeout would be extended by at least that
long. For example, code that waited (by polling the synthetic clock)
for 1s could easily wait an hour if the system clock stepped back that
far. Probaby undesirable.


Steven D'Aprano's synthetic clock is able to partially avoid that 
situation -- worst case is a timeout of double what you asked for -- so 
10 seconds instead of 5 (which is much better than 3600!).


~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

[Oleg Broytman]

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 Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

[Oleg Broytman]

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 Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Antoine Pitrou]

On Thu, 05 Apr 2012 08:32:22 -0700
Ethan Furman  wrote:
> 
> Steven D'Aprano's synthetic clock is able to partially avoid that 
> situation -- worst case is a timeout of double what you asked for -- so 
> 10 seconds instead of 5 (which is much better than 3600!).

The remaining issue is that the clock is not system-wide, it's
interpreter-specific.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[PJ Eby]

On Wed, Apr 4, 2012 at 11:41 PM, Cameron Simpson  wrote:

> On 04Apr2012 22:23, PJ Eby  wrote:
> | On Apr 4, 2012 7:28 PM, "Victor Stinner" 
> wrote:
> | > More details why it's hard to define such function and why I dropped
> | > it from the PEP.
> | >
> | > If someone wants to propose again such function ("monotonic or
> | > fallback to system" clock), two issues should be solved:
> | >
> | >  - name of the function
> | >  - description of the function
> |
> | Maybe I missed it, but did anyone ever give a reason why the fallback
> | couldn't be to Steven D'Aprano's monotonic wrapper algorithm over the
> | system clock?  (Given a suitable minimum delta.)  That function appeared
> to
> | me to provide a sufficiently monotonic clock for timeout purposes, if
> | nothing else.
>
> It was pointed out (by Nick Coglan I think?) that if the system clock
> stepped backwards then a timeout would be extended by at least that
> long. For example, code that waited (by polling the synthetic clock)
> for 1s could easily wait an hour if the system clock stepped back that
> far. Probaby undesirable.
>

Steven D'Aprano's algorithm doesn't do that.  If the system clock steps
backwards, it still stepped forward by a specified minimum delta.  The
amount of time that a timeout was extended would be a function of the
polling frequency, not the presence of absence of backward steps in the
underlying clock.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[PJ Eby]

On Thu, Apr 5, 2012 at 6:34 AM, Victor Stinner wrote:

> 2012/4/5 PJ Eby :
> >> More details why it's hard to define such function and why I dropped
> >> it from the PEP.
> >>
> >> If someone wants to propose again such function ("monotonic or
> >> fallback to system" clock), two issues should be solved:
> >>
> >>  - name of the function
> >>  - description of the function
> >
> > Maybe I missed it, but did anyone ever give a reason why the fallback
> > couldn't be to Steven D'Aprano's monotonic wrapper algorithm over the
> system
> > clock?  (Given a suitable minimum delta.)  That function appeared to me
> to
> > provide a sufficiently monotonic clock for timeout purposes, if nothing
> > else.
>
>
> Did you read the following section of the PEP?
>
> http://www.python.org/dev/peps/pep-0418/#working-around-operating-system-bugs
>
> Did I miss something? If yes, could you write a patch for the PEP please?
>

What's missing is that if you're using a monotonic clock for timeouts, then
a monotonically-adjusted system clock can do that, subject to the polling
frequency -- it does not break just because the system clock is set
backwards; it simply loses time proportional to the frequency with which it
is polled.

For timeout purposes in a single process, such a clock is useful.  It just
isn't suitable for benchmarks, or for interprocess coordination.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Guido van Rossum]

On Thu, Apr 5, 2012 at 9:48 AM, PJ Eby  wrote:
>
>
> On Thu, Apr 5, 2012 at 6:34 AM, Victor Stinner 
> wrote:
>>
>> 2012/4/5 PJ Eby :
>> >> More details why it's hard to define such function and why I dropped
>> >> it from the PEP.
>> >>
>> >> If someone wants to propose again such function ("monotonic or
>> >> fallback to system" clock), two issues should be solved:
>> >>
>> >>  - name of the function
>> >>  - description of the function
>> >
>> > Maybe I missed it, but did anyone ever give a reason why the fallback
>> > couldn't be to Steven D'Aprano's monotonic wrapper algorithm over the
>> > system
>> > clock?  (Given a suitable minimum delta.)  That function appeared to me
>> > to
>> > provide a sufficiently monotonic clock for timeout purposes, if nothing
>> > else.
>>
>>
>> Did you read the following section of the PEP?
>>
>> http://www.python.org/dev/peps/pep-0418/#working-around-operating-system-bugs
>>
>> Did I miss something? If yes, could you write a patch for the PEP please?
>
>
> What's missing is that if you're using a monotonic clock for timeouts, then
> a monotonically-adjusted system clock can do that, subject to the polling
> frequency -- it does not break just because the system clock is set
> backwards; it simply loses time proportional to the frequency with which it
> is polled.

Depending on the polling frequency sounds like a bad idea, since you
can't know that you're the only user of the clock. Also depending on
the use case, too short a timeout may be worse than too long a
timeout. E.g. imagine hitting a website that usually takes 2 seconds
to respond, and setting a timeout to e.g. 4 seconds to bail. If the
timeout somehow gets reduced to 1 second it will appear as if the
website died, whereas if the timeout was increased to 1 hour, nothing
bad would happen unless the website *actually* started having truly
bad response times.

> For timeout purposes in a single process, such a clock is useful.  It just
> isn't suitable for benchmarks, or for interprocess coordination.

I think it would be better if the proposed algorithm (or whatever
algorithm to "fix" timeouts) was implemented by the
application/library code using the timeout (or provided as a separate
library function), rather than by the clock, since the clock can't
know what fallback behavior the app/lib needs.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Antoine Pitrou]

On Thu, 5 Apr 2012 09:56:19 -0700
Guido van Rossum  wrote:
> 
> > For timeout purposes in a single process, such a clock is useful.  It just
> > isn't suitable for benchmarks, or for interprocess coordination.
> 
> I think it would be better if the proposed algorithm (or whatever
> algorithm to "fix" timeouts) was implemented by the
> application/library code using the timeout (or provided as a separate
> library function), rather than by the clock, since the clock can't
> know what fallback behavior the app/lib needs.

Agreed with providing it as a separate library function.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Issue #3033: Add displayof parameter to tkinter font.

[Terry Reedy]

On 4/5/2012 10:06 AM, R. David Murray wrote:

(reformatted to remove topposting)

On Thu, 05 Apr 2012 14:52:56 +0300, Andrew Svetlov  
wrote:

On Thu, Apr 5, 2012 at 1:21 PM, Antoine Pitrou  wrote:



Aren't there any docs?


Maybe you will be surprised, but tkinter.rst has no comprehensive docs
for any tkinter class.


There are doc strings to be updated. See below.


I like to get it fixed but definitely cannot do it myself. My very
poor English is the main objection for writing narrative
documentation.


One way to approach this problem would be to draft some rough docs that
try to capture the functionality without worrying about English content
or style.  Then you could post the rough draft somewhere, and ask for
someone from the docs mailing list to edit it.  My thought would be that
whoever took on the task would then do a rewrite, asking you questions
to fill in any details that aren't clear from the rough draft.

Thank, you, by the way, for all the work you are doing.


I have been hoping to work on a proper tkinter doc. I discovered some 
time ago through the pydoc server (not currently working for me, see 
http://bugs.python.org/issue14512)
that their are doc strings for (most) everything. I have been meaning to 
ask whether there is a way to build a draft doc from the doc strings. 
The first major editing job, given output like I saw in the browser, 
would be to remove the constant duplication of entries for inherited 
methods. Some widgets inherit perhaps a hundred methods and only add or 
override a couple. I guess the next question is whether a draft doc 
could be built *without* pulling in inherited methods.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Victor Stinner]

>> > For timeout purposes in a single process, such a clock is useful.  It just
>> > isn't suitable for benchmarks, or for interprocess coordination.
>>
>> I think it would be better if the proposed algorithm (or whatever
>> algorithm to "fix" timeouts) was implemented by the
>> application/library code using the timeout (or provided as a separate
>> library function), rather than by the clock, since the clock can't
>> know what fallback behavior the app/lib needs.
>
> Agreed with providing it as a separate library function.

I changed time.monotonic() to not fallback to the system clock exactly
for this reason: Python cannot guess what the developer expects, or
how the developer will use the clock.

Instead of implementing your own clock in your application, it's maybe
easier to patch your OS? I suppose that you are running on GNU/Hurd,
because I didn't find yet other OS not providing a monotonic clock :-)

If you are using an OS that doesn't provide a monotonic clock, do you
really need to implement your own in your application?

Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Ethan Furman]

Victor Stinner wrote:

I changed time.monotonic() to not fallback to the system clock exactly
for this reason: Python cannot guess what the developer expects, or
how the developer will use the clock.


Which is exactly why I like Cameron Simpson's approach to selecting a 
clock -- let the developer/user decide what kind of clock they need, and 
ask for one that matches their criteria.


~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[PJ Eby]

On Thu, Apr 5, 2012 at 12:56 PM, Guido van Rossum  wrote:

> Depending on the polling frequency sounds like a bad idea, since you
> can't know that you're the only user of the clock. Also depending on
> the use case, too short a timeout may be worse than too long a
> timeout.


Given a small enough delta, the timeout won't be too short. (Steven's
original code sample I believed used either 0 or 1 as a delta, but it could
be as small a fraction as will add correctly in the datatype used.)   And
the worst case polling frequency is the length of the timeout, meaning you
can't end up with more than double your intended timeout.

In the opposite scenario, where the time is polled in a tight loop, then as
long as Python doesn't sample the raw clock so often that the summed
fractional deltas exceeds the real clock speed, the timeout won't be
shortened by any appreciable amount.  In fact, this can be guaranteed by
measuring time as a (raw, increment) tuple, where the increment can be an
arbitrarily-large integer.  Each new time value is greater than the one
before, yet the real component remains untouched.  With this approach, the
timeout can only be delayed for however long the system clock *stops*, and
the timeout can only be shortened by the system clock skipping ahead.

Okay, having thought that out, I now agree that there are too many fine
points to make this cover enough of the use cases without needing
parameters.

Or more to the point, "If the implementation is hard to explain, it's a bad
idea."  ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Zooko Wilcox-O'Hearn]

Folks:

Good job, Victor Stinner on baking the accumulated knowledge of this
thread into PEP 418. Even though I'm very interested in the topic, I
haven't been able to digest the whole thread(s) on the list and
understand what the current collective understanding is. The detailed
PEP document helps a lot.

I think there are still some mistakes, either in our collective
understanding as reflected by the PEP, or in my own head.

For starters, I still don't understand the first, most basic thing:
what do people mean when they say "monotonic clock"? I don't
understand the current text of PEP 418 with regard to the definition
of that word.

Allow me to resort to an analogy. There is an infinitely long,
perfectly straight and flat racetrack. There is a flag that gets
dragged along it at a constant rate, with the label "REAL TIME" on the
flag. There are some runners, each with a different label on their
chest:

Runner A: a helicopter hovers over Runner A. Occasionally it picks him
up and plops him down right next to the flag. Also, he wears a headset
and listens to instructions from his coach to run a little faster or
slower, as necessary, to remain abreast of the flag.

Runner B: a helicopter hovers over Runner B. If he is behind the flag,
it will pick him up and plop him down right next to the flag. However,
if he is ahead of the flag it will not pick him up.

Runner C: no helicopter ever picks up Runner C, but he does wear a
headset and listens to instructions from his coach to run a little
faster or a little slower. His coach tells him to run a little faster
if he is behind the flag or run a little slower if he is in front of
the flag, with the goal of eventually having him right next to the
flag.

Runner D: like Runner C, he never gets picked up, but he listens to
instructions to run a little faster or a little slower. However,
instead of telling him to run faster in order to catch up to the flag,
or to run slower in order to "catch down" to the flag, his coach
instead tells him to run a little faster if he is moving slower than
the flag is moving, and to run a little slower if he is moving faster
than the flag is moving. Note that this is very different from Runner
C, in that it is not intended to cause him to eventually be right next
to the flag, and indeed if it is done right it guarantees that he will
*never* be right next to the flag, although he will be moving just as
fast as the flag is moving.

Runner E: no helicopter, no headset. He just proceeds at his own pace,
blissfully unaware of the exhortations of others.

Now: which ones of these five runners do you call "monotonic"? Which
ones do you call "steady"?

Regards,

Zooko
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

[Ethan Furman]

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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

[Oleg Broytman]

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 Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Issue #3033: Add displayof parameter to tkinter font.

[Andrew Svetlov]

On Thu, Apr 5, 2012 at 8:19 PM, Terry Reedy  wrote:
>
> I have been hoping to work on a proper tkinter doc. I discovered some time
> ago through the pydoc server (not currently working for me, see
> http://bugs.python.org/issue14512)
> that their are doc strings for (most) everything. I have been meaning to ask
> whether there is a way to build a draft doc from the doc strings.

I'll do it. Frankly speaking I don't like to do, 'hate' is better word
to describe my opinion.
But somebody need to make tkinter docs consistent.
I doubt if that work can be done by some script well enough —
docstrings should to be reformatted according
to Sphinx markup.

Please after I will finish initial transform help me to make this part
of documentation as good as Python Docs should be.
I think the excellent narrative Python documentation makes a big deal
in python wide spreading.
I remember docs for 1.5. Not so bad, but it's incompatible to docs for now.

Also, please help me to make hg clone for tk documentation located in
hg.python.org.
I tried to:
andrew@tiktaalik2 ~/projects> hg clone ssh://h...@hg.python.org/cpython
ssh://h...@hg.python.org/sandbox/tkdocs
repo created, public URL is http://hg.python.org/sandbox/tkdocs
abort: clone from remote to remote not supported
http://hg.python.org/sandbox/tkdocs is empty.

Looks like I don't know Mercurial well enough to to it.
When I'll get online clone of cpython available to myself as well as
visible to everyone and write accessible to python committers
(I hope you will push updates as well) — I will start to do.




-- 
Thanks,
Andrew Svetlov
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

[Ethan Furman]

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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

[Cameron Simpson]

On 05Apr2012 03:05, 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.

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  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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

[Cameron Simpson]

On 06Apr2012 00:15, Oleg Broytman  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  DoD#743
http://www.cskk.ezoshosting.com/cs/

Sam Jones  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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418

[Cameron Simpson]

On 05Apr2012 10:21, Lennart Regebro  wrote:
| On Thu, Apr 5, 2012 at 01:10, Victor Stinner  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  DoD#743
http://www.cskk.ezoshosting.com/cs/

>From the EXUP mailing list   ...
Wayne Girdlestone :
WG> Let's say there are no Yamaha's or Kawa's in the world.
Stevey Racer :
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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Cameron Simpson]

On 05Apr2012 09:56, Guido van Rossum  wrote:
| On Thu, Apr 5, 2012 at 9:48 AM, PJ Eby  wrote:
| > What's missing is that if you're using a monotonic clock for timeouts, then
| > a monotonically-adjusted system clock can do that, subject to the polling
| > frequency -- it does not break just because the system clock is set
| > backwards; it simply loses time proportional to the frequency with which it
| > is polled.
| 
| Depending on the polling frequency sounds like a bad idea, since you
| can't know that you're the only user of the clock.

You can if you're handed a shiny new "clock" object in some way, with a
not-a-singleton guarrentee. Of course, such a clock is immediately
_less_ reliable to synchornisation with other clock users:-)

| Also depending on
| the use case, too short a timeout may be worse than too long a
| timeout. [...]
|
| > For timeout purposes in a single process, such a clock is useful.  It just
| > isn't suitable for benchmarks, or for interprocess coordination.
| 
| I think it would be better if the proposed algorithm (or whatever
| algorithm to "fix" timeouts) was implemented by the
| application/library code using the timeout (or provided as a separate
| library function), rather than by the clock, since the clock can't
| know what fallback behavior the app/lib needs.

Absolutely. I for one would be happy with a clocktools module or
something offering a bunch of synthetic clocks. Especially if they were
compatible in API with whatever clock objects the core time module
clocks used, so that a user _could_ add them into the pick-a-clock
decision easily.

Cheers,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

I'd be careful who you call smart or not smart. Smart isn't knowing how to
save six bytes. Smart is knowing WHEN. - Peter Cherna, Amiga O.S. Development
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418

[Victor Stinner]

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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Cameron Simpson]

On 05Apr2012 13:39, Zooko Wilcox-O'Hearn  wrote:
| Good job, Victor Stinner on baking the accumulated knowledge of this
| thread into PEP 418. Even though I'm very interested in the topic, I
| haven't been able to digest the whole thread(s) on the list and
| understand what the current collective understanding is.

There isn't a collective understanding :-) That's why all the noise!

| The detailed
| PEP document helps a lot.

Yes indeed, though like all of us I think it could (always) use more
detail on my pet concerns.

| I think there are still some mistakes, either in our collective
| understanding as reflected by the PEP, or in my own head.
| 
| For starters, I still don't understand the first, most basic thing:
| what do people mean when they say "monotonic clock"? I don't
| understand the current text of PEP 418 with regard to the definition
| of that word.

A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent
polls of the clock. On its own it says nothing about steadiness or
correlation with real world time.

_Quality of implementation_ says that the montonic() call should try to
return a close that is monotonic and _also_ steady and preferably
precise. How these things are balancer is a matter of policy.

| Allow me to resort to an analogy. There is an infinitely long,
| perfectly straight and flat racetrack. There is a flag that gets
| dragged along it at a constant rate, with the label "REAL TIME" on the
| flag. There are some runners, each with a different label on their
| chest:
| 
| Runner A: a helicopter hovers over Runner A. Occasionally it picks him
| up and plops him down right next to the flag. Also, he wears a headset
| and listens to instructions from his coach to run a little faster or
| slower, as necessary, to remain abreast of the flag.

If he always runs forwards, it is montonic. Not very steady when the
helicopter comes to play.

| Runner B: a helicopter hovers over Runner B. If he is behind the flag,
| it will pick him up and plop him down right next to the flag. However,
| if he is ahead of the flag it will not pick him up.

Seems like runner A without instruction. Monotonic. Not very steady.

| Runner C: no helicopter ever picks up Runner C, but he does wear a
| headset and listens to instructions from his coach to run a little
| faster or a little slower. His coach tells him to run a little faster
| if he is behind the flag or run a little slower if he is in front of
| the flag, with the goal of eventually having him right next to the
| flag.

If he always runs forward, monotonic. And steady.

| Runner D: like Runner C, he never gets picked up, but he listens to
| instructions to run a little faster or a little slower. However,
| instead of telling him to run faster in order to catch up to the flag,
| or to run slower in order to "catch down" to the flag, his coach
| instead tells him to run a little faster if he is moving slower than
| the flag is moving, and to run a little slower if he is moving faster
| than the flag is moving. Note that this is very different from Runner
| C, in that it is not intended to cause him to eventually be right next
| to the flag, and indeed if it is done right it guarantees that he will
| *never* be right next to the flag, although he will be moving just as
| fast as the flag is moving.
| 
| Runner E: no helicopter, no headset. He just proceeds at his own pace,
| blissfully unaware of the exhortations of others.
| 
| Now: which ones of these five runners do you call "monotonic"? Which
| ones do you call "steady"?

If they all run forwards, they're all monotonic.

If their coach or helicopter can move then _backwards_ they're not
monotonic. If the helicopter can move them an arbitrary (but matching
the game plan) distance, they're not steady. Otherwise they are steady,
if the runner's speed is always sufficiently close to the flag speed
(this threshold and the criteria for measuring it as subject to debate,
forming policy).

And "high resolution" has its own flavours, though generally less
contentious.

Cheers,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

If you don't shoot the fish in your barrel, your barrel will soon be
full of fish. - Tim Mefford
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418

[Cameron Simpson]

On 06Apr2012 00:27, Victor Stinner  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  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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Eric Snow]

On Apr 5, 2012 11:01 AM, "Guido van Rossum"  wrote:
> I think it would be better if the proposed algorithm (or whatever
> algorithm to "fix" timeouts) was implemented by the
> application/library code using the timeout (or provided as a separate
> library function), rather than by the clock, since the clock can't
> know what fallback behavior the app/lib needs.

+1

-eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418

[Cameron Simpson]

On 06Apr2012 08:51, I wrote:
| On 06Apr2012 00:27, Victor Stinner  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  DoD#743
http://www.cskk.ezoshosting.com/cs/

Uh, this is only temporary...unless it works.   - Red Green
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Greg Ewing]

Cameron Simpson wrote:


A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent
polls of the clock. On its own it says nothing about steadiness or
correlation with real world time.


No, no, no.

This is the strict mathematical meaning of the word "monotonic",
but the way it's used in relation to OS clocks, it seems to
mean rather more than that.

A clock whose only guarantee is that it never goes backwards
is next to useless. For things like benchmarks and timeouts,
the important thing about a clock that it *keeps going forward*
at a reasonably constant rate. On the other hand, it can have
an arbitrary starting point and doesn't have to be related
to any external time standard.

I'm assuming this is what Linux et al mean when they talk
about a "monotonic clock", because anything else doesn't make
sense.

So if we're going to use the term "monotonic" at all, I think we
should explicitly define it as having this meaning, i.e.
both mathematically monotonic and steady. Failure to be clear
about this has caused a huge amount of confusion in this thead
so far.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Cameron Simpson]

On 06Apr2012 13:14, Greg Ewing  wrote:
| Cameron Simpson wrote:
| > A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent
| > polls of the clock. On its own it says nothing about steadiness or
| > correlation with real world time.
|
| No, no, no.
| This is the strict mathematical meaning of the word "monotonic",
| but the way it's used in relation to OS clocks, it seems to
| mean rather more than that.

It's like my next paragraph didn't exist...

  _Quality of implementation_ says that the montonic() call should try to
  return a close that is monotonic and _also_ steady and preferably precise.
  How these things are balancer is a matter of policy.

To forstall things, right at the bottom of this I'm going to say i agree
with you about objectives, but not about terminology. I maintain that
"monotonic" still means what I said, and that it is the combination of
the word with "clock" that brings in your other criteria.

| A clock whose only guarantee is that it never goes backwards
| is next to useless. For things like benchmarks and timeouts,
| the important thing about a clock that it *keeps going forward*
| at a reasonably constant rate. [...]
| I'm assuming this is what Linux et al mean when they talk
| about a "monotonic clock", because anything else doesn't make
| sense.

This is why I say there's no global understanding. Why assume?
On a Linux box, "man 3 clock_getres" says (sorry, this is a bit wordy):

   All  implementations  support the system-wide real-time clock, which
   is identified by CLOCK_REALTIME.  Its time represents seconds and
   nanoseconds  since the Epoch.  When its time is changed, timers for
   a relative interval are unaffected, but timers for an absolute point
   in time  are affected.

   More  clocks may be implemented.  The interpretation of the
   corresponding time values and the effect on timers is unspecified.

   Sufficiently recent versions of glibc and the Linux kernel support
   the following clocks:

   CLOCK_REALTIME
  System-wide real-time clock.  Setting this clock requires
  appropriate privileges.

   CLOCK_MONOTONIC
  Clock that cannot be set and  represents  monotonic  time since
  some unspecified starting point.

   CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
  Similar  to  CLOCK_MONOTONIC, but provides access to a raw hard-
  ware-based time that is not subject to NTP adjustments.

   CLOCK_PROCESS_CPUTIME_ID
  High-resolution per-process timer from the CPU.

   CLOCK_THREAD_CPUTIME_ID
  Thread-specific CPU-time clock.

The first paragraph is very clear about real time (wall clock, and what
time.time() does, being "seconds since the epoch"). The CLOCK_MONOTONIC*
modes clearly imply steadiness.

"man 3p clock_getres" (POSIX clock_getres) is even more verbose and general.

| So if we're going to use the term "monotonic" at all, I think we
| should explicitly define it as having this meaning, i.e.
| both mathematically monotonic and steady.

I think if it is too "unsteady" then it is not "time".

So I actually side with you in the requirement for a "clock", but
monotonic alone does not mean that. Quality of implementation _may_ mean
we don't offer something abjectly erratic.

| Failure to be clear
| about this has caused a huge amount of confusion in this thead
| so far.

And burdening the word "monotonic" itself with exciting new meanings
doesn't help. "monotonic clock", sure, _that_ has additional
connotations, but not just the word monotonic.

Cheers,
-- 
Cameron Simpson  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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Steven D'Aprano]

Greg Ewing wrote:

Cameron Simpson wrote:


A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent
polls of the clock. On its own it says nothing about steadiness or
correlation with real world time.


No, no, no.

This is the strict mathematical meaning of the word "monotonic",
but the way it's used in relation to OS clocks, it seems to
mean rather more than that.

A clock whose only guarantee is that it never goes backwards
is next to useless. For things like benchmarks and timeouts,
the important thing about a clock that it *keeps going forward*


That would be a *strictly* monotonic clock, as opposed to merely monotonic.

And yes, a merely monotonic clock could just return a constant value, forever:

9, 9, 9, 9, 9, ...

and yes, such a thing would be useless.

Various people have suggested caching the last value of time() and re-using it 
if the new value is in the past. This will give a monotonic clock, but since 
it can give constant timestamps for an indefinite period, it's usefulness is 
limited.


I earlier put forward an alternate implementation which gives no more than one 
such constant tick in a row. If you know the hardware resolution of the clock, 
you can even avoid that single constant tick by always advancing the timestamp 
by that minimum resolution:


_prev = _prev_raw = 0
_res = 1e-9  # nanosecond resolution
def monotonic():
global _prev, _prev_raw
raw = time()
delta = max(_res, raw - _prev_raw)
_prev_raw = raw
_prev += delta
return _prev

Even if time() jumps backwards, or stays constant, monotonic() here will be 
strictly monotonic.




--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

[Stephen J. Turnbull]

On Fri, Apr 6, 2012 at 12:22 AM, Oleg Broytman  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  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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

[Zooko Wilcox-O'Hearn]

On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing  wrote:
>
> This is the strict mathematical meaning of the word "monotonic", but the way 
> it's used in relation to OS clocks, it seems to mean rather more than that.

Yep. As far as I can tell, nobody has a use for an unsteady, monotonic clock.

There seem to be two groups of people:

1. Those who think that "monotonic clock" means a clock that never
goes backwards. These people are in the majority. After all, that's
what the word "monotonic" means ¹ . However, a clock which guarantees
*only* this is useless.

2. Those who think that "monotonic clock" means a clock that never
jumps, and that runs at a rate approximating the rate of real time.
This is a very useful kind of clock to have! It is what C++ now calls
a "steady clock". It is what all the major operating systems provide.

The people in class 1 are more correct, technically, and far more
numerous, but the concept from 1 is a useless concept that should be
forgotten.

So before proceeding, we should mutually agree that we have no
interest in implementing a clock of type 1. It wouldn't serve anyone's
use case (correct me if I'm wrong!) and the major operating systems
don't offer such a thing anyway.

Then, if we all agree to stop thinking about that first concept, then
we need to agree whether we're all going to use the word "monotonic
clock" to refer to the second concept, or if we're going to use a
different word (such as "steady clock") to refer to the second
concept. I would prefer the latter, as it will relieve us of the need
to repeatedly explain to newcomers: "That word doesn't mean what you
think it means.".

The main reason to use the word "monotonic clock" to refer to the
second concept is that POSIX does so, but since Mac OS X, Solaris,
Windows, and C++ have all avoided following POSIX's mistake, I think
Python should too.

Regards,

Zooko

¹ http://mathworld.wolfram.com/MonotonicSequence.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

[Cameron Simpson]

On 05Apr2012 21:07, Zooko Wilcox-O'Hearn  wrote:
| On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing  
wrote:
| > This is the strict mathematical meaning of the word "monotonic",
| > but the way it's used in relation to OS clocks, it seems to mean rather
| > more than that.
| 
| Yep. As far as I can tell, nobody has a use for an unsteady, monotonic clock.

Well, not for a wildly unsteady monotonic clock.

| There seem to be two groups of people:
| 1. Those who think that "monotonic clock" means a clock that never
| goes backwards.

I will always fall into this category.

| These people are in the majority. After all, that's
| what the word "monotonic" means ¹ . However, a clock which guarantees
| *only* this is useless.

Sure. I wouldn't have much use for a clock that was only monotonic, but
the word "clock" implies a bit more all on its own, so I am undisturbed.

| 2. Those who think that "monotonic clock" means a clock that never
| jumps, and that runs at a rate approximating the rate of real time.

If they're calling it "monotonic" on that basis alone, they are
wrong. Pure and simple.

| This is a very useful kind of clock to have! It is what C++ now calls
| a "steady clock". It is what all the major operating systems provide.

Sure. So _call_ it a steady clock!

| The people in class 1 are more correct, technically, and far more
| numerous, but the concept from 1 is a useless concept that should be
| forgotten.
| 
| So before proceeding, we should mutually agree that we have no
| interest in implementing a clock of type 1. It wouldn't serve anyone's
| use case (correct me if I'm wrong!) and the major operating systems
| don't offer such a thing anyway.

Bah! They are not disjoint sets of clocks!

Linux' CLOCK_MONOTONIC_RAW is both type 1 and type 2.

| Then, if we all agree to stop thinking about that first concept, then
| we need to agree whether we're all going to use the word "monotonic
| clock" to refer to the second concept,

No.

| or if we're going to use a
| different word (such as "steady clock") to refer to the second
| concept. I would prefer the latter, as it will relieve us of the need
| to repeatedly explain to newcomers: "That word doesn't mean what you
| think it means.".

Yes. Resorting to The Princess Bride to resolve bad terminology is only
funny in a movie, and should be a Big Clue that the term is either being
misused or too badly understood.

| The main reason to use the word "monotonic clock" to refer to the
| second concept is that POSIX does so, but since Mac OS X, Solaris,
| Windows, and C++ have all avoided following POSIX's mistake, I think
| Python should too.

No. If it is not monotonic, DO NOT CALL IT monotonic. Call it steady,
perhaps, if it _is_ steady (within some threshold of course).

But CLOCK_MONOTONIC_RAW is type 1 and 2, and is thus a "steady
monotonic" clock. Probably a good choice for both.

We can argue about what characteristics a useful clock has.
And we can argue about what characteristics the various OS clocks
possess.

But please DO NOT invent a new and misleading meaning for a well defined
word. "monotonic" alone is such a word, and means just one thing.
"monotonic clock" means _more_, but isn't always a requirement; "steady
clock" seems more commonly wanted.

Except of course that some participants say "steady clock" is a
nonsensical term.
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

Politics, n. Strife of interests masquerading as a contest of principles.
- Ambrose Bierce, _The_Devil's_Dictionary_
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

[Steven D'Aprano]

Cameron Simpson wrote:


| The main reason to use the word "monotonic clock" to refer to the
| second concept is that POSIX does so, but since Mac OS X, Solaris,
| Windows, and C++ have all avoided following POSIX's mistake, I think
| Python should too.

No. If it is not monotonic, DO NOT CALL IT monotonic. Call it steady,
perhaps, if it _is_ steady (within some threshold of course).


Um, steady is a stronger promise than monotonic. This is a monotonic sequence:

1, 2, 99, 100, 101, 102, 103, 199, 200, 201, 999

But it isn't steady, because it jumps forward.

Here is a non-monotonic sequence:

1, 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7, 8

This isn't steady either, because it jumps backwards.

To be steady, it MUST also be monotonic. If you think that it is appropriate 
to call a non-monotonic clock "steady", then I think you should tell us what 
you mean by "steady but not monotonic".




--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

[Cameron Simpson]

On 06Apr2012 14:31, Steven D'Aprano  wrote:
| Cameron Simpson wrote:
| > | The main reason to use the word "monotonic clock" to refer to the
| > | second concept is that POSIX does so, but since Mac OS X, Solaris,
| > | Windows, and C++ have all avoided following POSIX's mistake, I think
| > | Python should too.
| > 
| > No. If it is not monotonic, DO NOT CALL IT monotonic. Call it steady,
| > perhaps, if it _is_ steady (within some threshold of course).
| 
| Um, steady is a stronger promise than monotonic. This is a monotonic sequence:
| 
| 1, 2, 99, 100, 101, 102, 103, 199, 200, 201, 999
| 
| But it isn't steady, because it jumps forward.

Sure.

| Here is a non-monotonic sequence:
| 
| 1, 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7, 8
| 
| This isn't steady either, because it jumps backwards.
| 
| To be steady, it MUST also be monotonic. If you think that it is appropriate 
| to call a non-monotonic clock "steady", then I think you should tell us what 
| you mean by "steady but not monotonic".

I took steady to mean "never jumps more than x", for "x" being "small",
and allowing small negatives. If steady implies monotonic and people
agree that that is so, I'm happy too, and happy that steady is a better
aspiration than merely monotonic.
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

I understand a fury in your words, but not your words.  - William Shakespeare
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

[Glyph Lefkowitz]

On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote:

> On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing  
> wrote:
>> 
>> This is the strict mathematical meaning of the word "monotonic", but the way 
>> it's used in relation to OS clocks, it seems to mean rather more than that.
> 
> Yep. As far as I can tell, nobody has a use for an unsteady, monotonic clock.
> 
> There seem to be two groups of people:
> 
> 1. Those who think that "monotonic clock" means a clock that never
> goes backwards. These people are in the majority. After all, that's
> what the word "monotonic" means ¹ . However, a clock which guarantees
> *only* this is useless.

While this is a popular view on this list and in this discussion, it is also a 
view that seems to contradict quite a lot that has been written on the subject, 
and seems contrary to the usual jargon when referring to clocks.

> 2. Those who think that "monotonic clock" means a clock that never
> jumps, and that runs at a rate approximating the rate of real time.
> This is a very useful kind of clock to have! It is what C++ now calls
> a "steady clock". It is what all the major operating systems provide.

All clocks run at a rate approximating the rate of real time.  That is very 
close to the definition of the word "clock" in this context.  All clocks have 
flaws in that approximation, and really those flaws are the whole point of 
access to distinct clock APIs.  Different applications can cope with different 
flaws.

There seems to be a persistent desire in this discussion to specify and define 
these flaws out of existence, where this API really should instead be embracing 
the flaws and classifying them.  (Victor is doing a truly amazing job with the 
PEP in that regard; it's already the first web search hit on every search 
engine I've tried for more than half of these terms.)

Steadiness, in the C++ sense, only applies to most OS clocks that are given the 
label of "monotonic" during the run of a single program on a single computer 
while that computer is running at some close approximation of full power.

As soon as you close your laptop lid, the property of steadiness with respect 
to real local time goes away; the clock stops ticking forward, and only resumes 
when the lid is opened again.  The thing I'd like to draw attention to here is 
that when you get one of these clocks, you *do not* get a parallel facility 
that allows you to identify whether a suspend has happened (or, for that 
matter, when the wall clock has stepped).  Or at least, nobody's proposed one 
for Python.  I proposed one for Twisted, 
, but you need an event 
loop for that, because you need to be able to register interest in that event.

I believe that the fact that these clocks are only semi-steady, or only steady 
with respect to certain kinds of time, is why the term "monotonic clock" 
remains so popular, despite the fact that mathematical monotonicity is not 
actually their most useful property.  While these OS-provided clocks have other 
useful properties, they only have those properties under specific conditions 
which you cannot necessarily detect and you definitely cannot enforce.  But 
they all remain monotonic in the mathematical sense (modulo hardware and OS 
bugs), so it is the term "monotonic" which comes to label all their other, more 
useful, but less reliable properties.

> The people in class 1 are more correct, technically, and far more
> numerous, but the concept from 1 is a useless concept that should be
> forgotten.

Technically correct; the best kind of correct!

The people in class 1 are only more correct if you accept that mis-applying 
jargon from one field (mathematics) to replace generally-accepted terminology 
in another field (software clocks) is the right thing to do.  I think it's 
better to learn the local jargon and try to apply it consistently.  If you 
search around the web for the phrase "monotonic clock", it's applied in a sense 
closest to the one you mean on thousands and thousands of web pages.  "steady 
clock" generally applies with reference to C++, and even then is often found in 
phrases like "is_steady indicates whether this clock is a monotonic clock".

Software developers "mis"-apply mathematical terms like "isomorphic", 
"orthogonal", "incidental", "tangential", and "reflexive" all the time.  
Physicists and mathematicians also disagree on the subtleties of the same 
terms.  Context is everything.

> So before proceeding, we should mutually agree that we have no
> interest in implementing a clock of type 1. It wouldn't serve anyone's
> use case (correct me if I'm wrong!) and the major operating systems
> don't offer such a thing anyway.

+1.

> Then, if we all agree to stop thinking about that first concept, then
> we need to agree whether we're all going to use the word "monotonic
> clock" to refer to the second concept, or if we're going to use a
> different word (such as "steady clock") to