Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
On Thu, Apr 5, 2012 at 00:45, Greg Ewing greg.ew...@canterbury.ac.nz 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
On Thu, Apr 5, 2012 at 01:10, Victor Stinner victor.stin...@gmail.com wrote: 2012/4/4 Lennart Regebro rege...@gmail.com: On Wed, Apr 4, 2012 at 13:04, Victor Stinner victor.stin...@gmail.com 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.
On Thu, 05 Apr 2012 11:41:48 +0200 andrew.svetlov python-check...@python.org wrote: http://hg.python.org/cpython/rev/774c2afa6665 changeset: 76115:774c2afa6665 user:Andrew Svetlov andrew.svet...@gmail.com 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
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
2012/4/5 PJ Eby p...@telecommunity.com: 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.
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 solip...@pitrou.net wrote: On Thu, 05 Apr 2012 11:41:48 +0200 andrew.svetlov python-check...@python.org wrote: http://hg.python.org/cpython/rev/774c2afa6665 changeset: 76115:774c2afa6665 user: Andrew Svetlov andrew.svet...@gmail.com 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
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 krist...@ccpgames.com 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 rep...@bugs.python.org http://bugs.python.org/issue9141 ___ ___ 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)
On Thu, Apr 5, 2012 at 8:05 AM, Oleg Broytman p...@phdru.name 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)
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 p...@phdru.name 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.
(reformatted to remove topposting) On Thu, 05 Apr 2012 14:52:56 +0300, Andrew Svetlov andrew.svet...@gmail.com wrote: On Thu, Apr 5, 2012 at 1:21 PM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 05 Apr 2012 11:41:48 +0200 andrew.svetlov python-check...@python.org wrote: http://hg.python.org/cpython/rev/774c2afa6665 changeset: Â 76115:774c2afa6665 user: Â Â Â Â Andrew Svetlov andrew.svet...@gmail.com 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.
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 rdmur...@bitdance.com wrote: (reformatted to remove topposting) On Thu, 05 Apr 2012 14:52:56 +0300, Andrew Svetlov andrew.svet...@gmail.com wrote: On Thu, Apr 5, 2012 at 1:21 PM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 05 Apr 2012 11:41:48 +0200 andrew.svetlov python-check...@python.org wrote: http://hg.python.org/cpython/rev/774c2afa6665 changeset: 76115:774c2afa6665 user: Andrew Svetlov andrew.svet...@gmail.com 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)
On Thu, Apr 5, 2012 at 10:34 PM, Oleg Broytman p...@phdru.name 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)
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 p...@phdru.name 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.
On Thu, 05 Apr 2012 17:34:07 +0300, Andrew Svetlov andrew.svet...@gmail.com 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)
On Thu, 05 Apr 2012 19:22:17 +0400, Oleg Broytman p...@phdru.name 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 p...@phdru.name 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
Cameron Simpson wrote: On 04Apr2012 22:23, PJ Eby p...@telecommunity.com wrote: | On Apr 4, 2012 7:28 PM, Victor Stinner victor.stin...@gmail.com 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)
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)
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
On Thu, 05 Apr 2012 08:32:22 -0700 Ethan Furman et...@stoneleaf.us 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
On Wed, Apr 4, 2012 at 11:41 PM, Cameron Simpson c...@zip.com.au wrote: On 04Apr2012 22:23, PJ Eby p...@telecommunity.com wrote: | On Apr 4, 2012 7:28 PM, Victor Stinner victor.stin...@gmail.com 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
On Thu, Apr 5, 2012 at 6:34 AM, Victor Stinner victor.stin...@gmail.comwrote: 2012/4/5 PJ Eby p...@telecommunity.com: 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
On Thu, Apr 5, 2012 at 9:48 AM, PJ Eby p...@telecommunity.com wrote: On Thu, Apr 5, 2012 at 6:34 AM, Victor Stinner victor.stin...@gmail.com wrote: 2012/4/5 PJ Eby p...@telecommunity.com: 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
On Thu, 5 Apr 2012 09:56:19 -0700 Guido van Rossum gu...@python.org 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.
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 Svetlovandrew.svet...@gmail.com wrote: On Thu, Apr 5, 2012 at 1:21 PM, Antoine Pitrousolip...@pitrou.net 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
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
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
On Thu, Apr 5, 2012 at 12:56 PM, Guido van Rossum gu...@python.org 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
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)
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)
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.
On Thu, Apr 5, 2012 at 8:19 PM, Terry Reedy tjre...@udel.edu 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)
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)
On 05Apr2012 03:05, Oleg Broytman p...@phdru.name 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 c...@zip.com.au 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)
On 06Apr2012 00:15, Oleg Broytman p...@phdru.name 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 c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Sam Jones samjo...@leo.unm.edu 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
On 05Apr2012 10:21, Lennart Regebro rege...@gmail.com wrote: | On Thu, Apr 5, 2012 at 01:10, Victor Stinner victor.stin...@gmail.com 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 c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ From the EXUP mailing list exup-brotherh...@majordomo.net ... Wayne Girdlestone way...@mega.co.za: WG Let's say there are no Yamaha's or Kawa's in the world. Stevey Racer sst...@co.la.ca.us: 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
On 05Apr2012 09:56, Guido van Rossum gu...@python.org wrote: | On Thu, Apr 5, 2012 at 9:48 AM, PJ Eby p...@telecommunity.com 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 c...@zip.com.au 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
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
On 05Apr2012 13:39, Zooko Wilcox-O'Hearn zo...@zooko.com 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 c...@zip.com.au 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
On 06Apr2012 00:27, Victor Stinner victor.stin...@gmail.com 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 c...@zip.com.au 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
On Apr 5, 2012 11:01 AM, Guido van Rossum gu...@python.org 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
On 06Apr2012 08:51, I wrote: | On 06Apr2012 00:27, Victor Stinner victor.stin...@gmail.com 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 c...@zip.com.au 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
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
On 06Apr2012 13:14, Greg Ewing greg.ew...@canterbury.ac.nz 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 c...@zip.com.au 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
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)
On Fri, Apr 6, 2012 at 12:22 AM, Oleg Broytman p...@phdru.name 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 p...@phdru.name 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)
On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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)
On 05Apr2012 21:07, Zooko Wilcox-O'Hearn zo...@zooko.com wrote: | On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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 c...@zip.com.au 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)
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)
On 06Apr2012 14:31, Steven D'Aprano st...@pearwood.info 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 c...@zip.com.au 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
