Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
On Thu, Apr 5, 2012 at 21:57, Stephen J. Turnbull step...@xemacs.org wrote: I might have chosen to implement a 'None' return if I had designed open(), but I can't get too upset about raising an Exception as it actually does. One fundamental difference is that there are many reasons one might fail to open a file. It may not exist. It may not have permissions allowing the request. It may be locked. If open() returned None, this information would have to be retrievable through another function. However since it returns an exception, that information is already wrapped up in the exception object, should you choose to catch it, and likely to be logged otherwise. In the case of the clocks, I'm assuming the only reason you would fail to get a clock is because it isn't provided by hardware and/or OS. You don't have to worry about transient scenarios on multi-user systems where another user has locked the clock. Thus the exception cannot tell you anything more than None tells you. (Of course, if my assumption is wrong, I'm not sure whether my reasoning still applies.) -- Michael Urman ___ Python-Dev mailing list Python-Dev@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] 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] 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] 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] 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] 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 (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
Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
(Sorry, should have sent to the list). On 4 April 2012 01:04, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Cameron Simpson wrote: People have been saying hires throughout the threads I think, but I for one would be slightly happier with highres. hirez? What's wrong with high_resolution? Paul ___ Python-Dev mailing list Python-Dev@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 Tue, Apr 3, 2012 at 18:07, Ethan Furman et...@stoneleaf.us wrote: What's unclear about returning None if no clocks match? Nothing, but having to check error values on return functions are not what you typically do in Python. Usually, Python functions that fail raise an error. Please don't force Python users to write pseudo-C code in Python. //Lennart ___ Python-Dev mailing list Python-Dev@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)
Lennart Regebro wrote:
On Tue, Apr 3, 2012 at 18:07, Ethan Furman et...@stoneleaf.us wrote:
What's unclear about returning None if no clocks match?
Nothing, but having to check error values on return functions are not
what you typically do in Python. Usually, Python functions that fail
raise an error. Please don't force Python users to write pseudo-C code
in Python.
You mean like the dict.get() function?
-- repr({}.get('missing'))
'None'
Plus, failure mode is based on intent: if the intent is Give a clock
no matter what, then yes, an exception when that's not possible is the
way to go.
But if the intent is Give me a clock that matches this criteria then
returning None is perfectly reasonable.
~Ethan~
___
Python-Dev mailing list
Python-Dev@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 Wed, Apr 04, 2012 at 05:47:16PM +0200, Lennart Regebro wrote:
On Tue, Apr 3, 2012 at 18:07, Ethan Furman et...@stoneleaf.us wrote:
What's unclear about returning None if no clocks match?
Nothing, but having to check error values on return functions are not
what you typically do in Python. Usually, Python functions that fail
raise an error.
Absolutely. Errors should never pass silently.
Please don't force Python users to write pseudo-C code in Python.
+1. Pythonic equivalent of get_clock(THIS) or get_clok(THAT) is
for flag in (THIS, THAT):
try:
clock = get_clock(flag)
except:
pass
else:
break
else:
raise ValueError('Cannot get clock, tried THIS and THAT')
Oleg.
--
Oleg 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)
Am 04.04.2012 18:18, schrieb Ethan Furman:
Lennart Regebro wrote:
On Tue, Apr 3, 2012 at 18:07, Ethan Furman et...@stoneleaf.us wrote:
What's unclear about returning None if no clocks match?
Nothing, but having to check error values on return functions are not
what you typically do in Python. Usually, Python functions that fail
raise an error. Please don't force Python users to write pseudo-C code
in Python.
You mean like the dict.get() function?
-- repr({}.get('missing'))
'None'
Strawman: this is not a failure.
Georg
___
Python-Dev mailing list
Python-Dev@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 05:47:16PM +0200, Lennart Regebro wrote:
On Tue, Apr 3, 2012 at 18:07, Ethan Furman et...@stoneleaf.us wrote:
What's unclear about returning None if no clocks match?
Nothing, but having to check error values on return functions are not
what you typically do in Python. Usually, Python functions that fail
raise an error.
Absolutely. Errors should never pass silently.
Again, what's the /intent/? No matching clocks does not have to be an
error.
Please don't force Python users to write pseudo-C code in Python.
+1. Pythonic equivalent of get_clock(THIS) or get_clok(THAT) is
for flag in (THIS, THAT):
try:
clock = get_clock(flag)
except:
pass
else:
break
else:
raise ValueError('Cannot get clock, tried THIS and THAT')
Wow -- you'd rather write nine lines of code instead of three?
clock = get_clock(THIS) or get_clock(THAT)
if clock is None:
raise ValueError('Cannot get clock, tried THIS and THAT')
~Ethan~
___
Python-Dev mailing list
Python-Dev@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)
Georg Brandl wrote:
Am 04.04.2012 18:18, schrieb Ethan Furman:
Lennart Regebro wrote:
On Tue, Apr 3, 2012 at 18:07, Ethan Furman et...@stoneleaf.us wrote:
What's unclear about returning None if no clocks match?
Nothing, but having to check error values on return functions are not
what you typically do in Python. Usually, Python functions that fail
raise an error. Please don't force Python users to write pseudo-C code
in Python.
You mean like the dict.get() function?
-- repr({}.get('missing'))
'None'
Strawman: this is not a failure.
Also not a very good example -- if 'missing' was there with a value of
None the two situations could not be distinguished with the one call.
At any rate, the point is that there is nothing inherently wrong nor
unPythonic about a function returning None instead of raising an exception.
~Ethan~
___
Python-Dev mailing list
Python-Dev@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 Wed, Apr 04, 2012 at 11:03:02AM -0700, Ethan Furman wrote:
Oleg Broytman wrote:
. Pythonic equivalent of get_clock(THIS) or get_clok(THAT) is
for flag in (THIS, THAT):
try:
clock = get_clock(flag)
except:
pass
else:
break
else:
raise ValueError('Cannot get clock, tried THIS and THAT')
Wow -- you'd rather write nine lines of code instead of three?
clock = get_clock(THIS) or get_clock(THAT)
if clock is None:
raise ValueError('Cannot get clock, tried THIS and THAT')
Yes - to force people to write the last two lines. Without forcing
most programmers will skip them.
Oleg.
--
Oleg 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 wrote:
On Wed, Apr 04, 2012 at 11:03:02AM -0700, Ethan Furman wrote:
Oleg Broytman wrote:
. Pythonic equivalent of get_clock(THIS) or get_clok(THAT) is
for flag in (THIS, THAT):
try:
clock = get_clock(flag)
except:
pass
else:
break
else:
raise ValueError('Cannot get clock, tried THIS and THAT')
Wow -- you'd rather write nine lines of code instead of three?
clock = get_clock(THIS) or get_clock(THAT)
if clock is None:
raise ValueError('Cannot get clock, tried THIS and THAT')
Yes - to force people to write the last two lines. Without forcing
most programmers will skip them.
Forced? I do not use Python to be forced to use one style of
programming over another.
And it's not like returning None will allow some clock calls to work but
not others -- as soon as they try to use it, it will raise an exception.
~Ethan~
___
Python-Dev mailing list
Python-Dev@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 04Apr2012 19:47, Georg Brandl g.bra...@gmx.net wrote:
| Am 04.04.2012 18:18, schrieb Ethan Furman:
| Lennart Regebro wrote:
| On Tue, Apr 3, 2012 at 18:07, Ethan Furman et...@stoneleaf.us wrote:
| What's unclear about returning None if no clocks match?
|
| Nothing, but having to check error values on return functions are not
| what you typically do in Python. Usually, Python functions that fail
| raise an error. Please don't force Python users to write pseudo-C code
| in Python.
|
| You mean like the dict.get() function?
|
| -- repr({}.get('missing'))
| 'None'
|
| Strawman: this is not a failure.
And neither is get_clock() returning None. get_clock() is an inquiry
function, and None is a legitimate response when no clock is
satisfactory, just as a dict has no key for a get().
Conversely, monotonic() (gimme the time!) and indeed time() should
raise an exception if there is no clock. They're, for want of a word,
live functions you would routinely embed in a calculation.
So not so much a straw man as a relevant illuminating example.
--
Cameron Simpson c...@zip.com.au DoD#743
http://www.cskk.ezoshosting.com/cs/
A crash reduces
your expensive computer
to a simple stone.
- Haiku Error Messages
http://www.salonmagazine.com/21st/chal/1998/02/10chal2.html
___
Python-Dev mailing list
Python-Dev@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 Wed, Apr 04, 2012 at 12:52:00PM -0700, Ethan Furman wrote:
Oleg Broytman wrote:
On Wed, Apr 04, 2012 at 11:03:02AM -0700, Ethan Furman wrote:
Oleg Broytman wrote:
. Pythonic equivalent of get_clock(THIS) or get_clok(THAT) is
for flag in (THIS, THAT):
try:
clock = get_clock(flag)
except:
pass
else:
break
else:
raise ValueError('Cannot get clock, tried THIS and THAT')
Wow -- you'd rather write nine lines of code instead of three?
clock = get_clock(THIS) or get_clock(THAT)
if clock is None:
raise ValueError('Cannot get clock, tried THIS and THAT')
Yes - to force people to write the last two lines. Without forcing
most programmers will skip them.
Forced? I do not use Python to be forced to use one style of
programming over another.
Then it's strange you are using Python with its strict syntax
(case-sensitivity, forced indents), ubiquitous exceptions, limited
syntax of lambdas and absence of code blocks (read - forced functions),
etc.
And it's not like returning None will allow some clock calls to work
but not others -- as soon as they try to use it, it will raise an
exception.
There is a philosophical distinction between EAFP and LBYL. I am
mostly proponent of LBYL.
Well, I am partially retreat. Errors should never pass silently.
Unless explicitly silenced. get_clock(FLAG, on_error=None) could return
None.
Oleg.
--
Oleg 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 03Apr2012 07:51, Lennart Regebro rege...@gmail.com wrote: | I like the aim of letting the user control what clock it get, but I | find this API pretty horrible: | | clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC) FWIW, the leading T_ is now gone, so it would now read: clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC) If the symbol names are not the horribleness, can you qualify what API you would like more? -- Cameron Simpson 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] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
On 03/04/2012 07:03, Cameron Simpson wrote: On 03Apr2012 07:51, Lennart Regebrorege...@gmail.com wrote: | I like the aim of letting the user control what clock it get, but I | find this API pretty horrible: | |clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC) FWIW, the leading T_ is now gone, so it would now read: clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC) If the symbol names are not the horribleness, can you qualify what API you would like more? I reckon the API is ok given that you don't have to supply the flags, correct? A small point but I'm with (I think) Terry Reedy and Steven D'Aprano in that hires is an English word, could you please substitute highres and HIGHRES, thanks. -- Cheers. Mark Lawrence. ___ Python-Dev mailing list Python-Dev@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 03Apr2012 09:03, Mark Lawrence breamore...@yahoo.co.uk wrote: | On 03/04/2012 07:03, Cameron Simpson wrote: | On 03Apr2012 07:51, Lennart Regebrorege...@gmail.com wrote: | | I like the aim of letting the user control what clock it get, but I | | find this API pretty horrible: | | | |clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC) | | FWIW, the leading T_ is now gone, so it would now read: | | clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC) | | If the symbol names are not the horribleness, can you qualify what API | you would like more? | | I reckon the API is ok given that you don't have to supply the flags, | correct? That's right. And if the monotonic() or monotonic_clock() functions (or the hires* versions if suitable) do what you want you don't even need that. You only need the or style to choose your own fallback according to your own criteria. | A small point but I'm with (I think) Terry Reedy and Steven D'Aprano in | that hires is an English word, could you please substitute highres and | HIGHRES, thanks. I have the same issue and would be happy to do it. Victor et al, how do you feel about this? People have been saying hires throughout the threads I think, but I for one would be slightly happier with highres. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ I bested him in an Open Season of scouring-people's-postings-looking-for- spelling-errors.- ke...@rotag.mi.org (Kevin Darcy) ___ 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 Tue, Apr 3, 2012 at 08:03, Cameron Simpson c...@zip.com.au wrote: clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC) If the symbol names are not the horribleness, can you qualify what API you would like more? Well, get_clock(monotonic=True, highres=True) would be a vast improvement over get_clock(MONOTONIC|HIRES). I also think it should raise an error if not found. The clarity and easy of use of the API is much more important than how much you can do in one line. //Lennart ___ Python-Dev mailing list Python-Dev@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)
Lennart Regebro wrote: On Tue, Apr 3, 2012 at 08:03, Cameron Simpson c...@zip.com.au wrote: clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC) If the symbol names are not the horribleness, can you qualify what API you would like more? Well, get_clock(monotonic=True, highres=True) would be a vast improvement over get_clock(MONOTONIC|HIRES). Allowing get_clock(True, True)? Ick. My nomination would be get_clock(MONOTONIC, HIGHRES) -- easier on the eyes with no |. I also think it should raise an error if not found. The clarity and easy of use of the API is much more important than how much you can do in one line. What's unclear about returning None if no clocks match? Cheers, ~Ethan~ ___ Python-Dev mailing list Python-Dev@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 03Apr2012 09:07, Ethan Furman et...@stoneleaf.us wrote: | Lennart Regebro wrote: | On Tue, Apr 3, 2012 at 08:03, Cameron Simpson c...@zip.com.au wrote: | clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC) | | If the symbol names are not the horribleness, can you qualify what API | you would like more? | | Well, get_clock(monotonic=True, highres=True) would be a vast | improvement over get_clock(MONOTONIC|HIRES). | | Allowing get_clock(True, True)? Ick. My nomination would be | get_clock(MONOTONIC, HIGHRES) -- easier on the eyes with no |. get_clock already has two arguments - you can optionally hand it a clock list - that's used by monotonic_clock() and hires_clock(). Have a quick glance at: https://bitbucket.org/cameron_simpson/css/src/tip/lib/python/cs/clockutils.py (I finally found out how to point at the latest revision on BitBucket; it's not obvious from the web interface itself.) | I also think it should | raise an error if not found. The clarity and easy of use of the API is | much more important than how much you can do in one line. How much you can do _clearly_ in one line is a useful metric. | What's unclear about returning None if no clocks match? The return of None is very deliberate. I _want_ user specified fallback to be concise and easy. The example: clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC) seems to satisfy both these criteria to my eye. Raising an exception makes user fallback a royal PITA, with a horrible try/except cascade needed. Exceptions are all very well when there is just one thing to do: parse this or fail, divide this by that or fail. If fact they're the very image of do this one thing or FAIL. They are not such a good match for do this thing or that thing or this other thing. When you want a simple linear cascade of choices, Python's short circuiting or operator is a very useful thing. Having an obsession with exceptions is IMO unhealthy. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Because of its special customs, crossposting between alt.peeves and normal newsgroups is discouraged. - Cameron Spitzer ___ Python-Dev mailing list Python-Dev@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 wrote: get_clock already has two arguments - you can optionally hand it a clock list - that's used by monotonic_clock() and hires_clock(). def get_clock(*flags, *, clocklist=None): ''' Return a Clock based on the supplied `flags`. The returned clock shall have all the requested flags. If no clock matches, return None. ''' wanted = 0 for flag in flags: wanted |= flag if clocklist is None: clocklist = ALL_CLOCKS for clock in clocklist: if clock.flags wanted == wanted: return clock.factory() return None Would need to make *flags change to the other *_clock functions. Have a quick glance at: https://bitbucket.org/cameron_simpson/css/src/tip/lib/python/cs/clockutils.py Thanks. The return of None is very deliberate. I _want_ user specified fallback to be concise and easy. The example: clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC) Which would become: clock = get_clock(MONOTONIC, HIGHRES) or get_clock(MONOTONIC) +1 to returning None Exceptions are all very well when there is just one thing to do: parse this or fail, divide this by that or fail. If fact they're the very image of do this one thing or FAIL. They are not such a good match for do this thing or that thing or this other thing. When you want a simple linear cascade of choices, Python's short circuiting or operator is a very useful thing. Having an obsession with exceptions is IMO unhealthy. Another +1. ~Ethan~ ___ Python-Dev mailing list Python-Dev@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 03Apr2012 15:08, Ethan Furman et...@stoneleaf.us wrote: | Cameron Simpson wrote: | get_clock already has two arguments - you can optionally hand it a clock | list - that's used by monotonic_clock() and hires_clock(). | | def get_clock(*flags, *, clocklist=None): I presume that bare *, is a typo. Both my python2 and python3 commands reject it. [...] | wanted = 0 | for flag in flags: | wanted |= flag [...] I could do this. I think I'm -0 on it, because it doesn't seem more expressive to my eye than the straight make-a-bitmask | form. Other opinions? | Would need to make *flags change to the other *_clock functions. Yep. | The return of None is very deliberate. I _want_ user specified fallback | to be concise and easy. The example: |clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC) | | Which would become: | clock = get_clock(MONOTONIC, HIGHRES) or get_clock(MONOTONIC) | | +1 to returning None | | Exceptions are all very well when there is just one thing to do: parse | this or fail, divide this by that or fail. If fact they're the very | image of do this one thing or FAIL. They are not such a good match for do | this thing or that thing or this other thing. Another thought that occurred in the shower was that get_clock() et al are inquiry functions, and returning None is very sensible there. monotonic() et al are direct use functions, which should raise an exception if unavailable so that code like: t0 = monotonic() ... t1 = monotonic() does not become littered with checks for special values like None. I consider this additional reason to return None from get_clock(). Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ DON'T DRINK SOAP! DILUTE DILUTE! OK! - on the label of Dr. Bronner's Castile Soap ___ Python-Dev mailing list Python-Dev@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)
| get_clock() returns None if no clock has the requested flags, whereas | I expected an exception (LookupError or NotImplementError?). That is deliberate. People can easily write fallback like this: clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC) Why not passing a a list of set of flags? Example: haypo_steady = get_clock(MONOTONIC|STEADY, STEADY, MONOTONIC, REALTIME) # try to get a monotonic and steady clock, # or fallback to a steady clock, # or fallback to a monotonic clock, # or fallback to the system clock haypo_perf_counter = get_clock(HIGHRES, MONOTONIC|STEADY, STEADY, MONOTONIC, REALTIME) # try to get a high-resolution clock # or fallback to a monotonic and steady clock, # or fallback to a steady clock, # or fallback to a monotonic clock, # or fallback to the system clock On Windows, haypo_steady should give GetTickCount (MONOTONIC|STEADY) and haypo_perf_counter should give QueryPerformanceCounter (MONOTONIC|HIGHRES). Hum, I'm not sure that haypo_highres uses the same clocks than time.perf_counter() in the PEP. If one wants an exception it is easy to follow up with: if not clock: raise RunTimeError(no suitable clocks on offer on this platform) And if don't read the doc carefuly and forget the test, you can a NoneType object is not callable error. | get_clock() doesn't remember if a clock works or not (if it raises an | OSError) and does not fallback to the next clock on error. See | pseudo-codes in the PEP 418. I presume the available clocks are all deduced from the platform. Your pseudo code checks for OSError at fetch-the-clock time. I expect that to occur once when the module is loaded, purely to populate the table of avaiable platform clocks. It's better to avoid unnecessary system calls at startup (when the time module is loaded), but you may defer the creation of the clock list, or at least of the flags of each clock. Note that you don't need to provide a clock list at all; get_clock(0 will use ALL_CLOCKS by default, and hires() and monotonic() should each have their own default list. A list of clocks and a function are maybe redundant. Why not only providing a function? Regarding the choice itself: as the _caller_ (not the library author), you must decide what you want most. You're already planning offering monotonic() and hires() calls without my proposal! My PEP starts with use cases: it proposes one clock per use case. There is no If you need a monotonic, steady and high-resolution clock ... use case. The highres name was confusing, I just replaced it with time.perf_counter() (thanks Antoine for the name!). time.perf_counter() should be used for benchmarking and profiling. Taking your query Should I use MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and high-resolution clock is _already_ a problem. Of course you must call monotonic() or hires() first under the current scheme, and must answer this question anyway. Do you prefer hires? Use it first! No preference? Then the question does not matter. I mean having to choose the flags *and* the list of clocks is hard. I would prefer to only have to choose flags or only the list of clocks. The example was maybe not the best one. | If you have only one list of clocks, how do sort the list to get | QueryPerformanceCounter when the user asks for highres and | GetTickCount when the user asks for monotonic? This is exactly why there are supposed to be different lists. You have just argued against your objection above. You can solve this issue with only one list of clocks if you use the right set of flags. | So we would have: | | GetTickCount.flags = T_MONOTONIC | T_STEADY | T_HIGHRES | | Even if GetTickCount has only an accuracy of 15 ms :-/ T_HIGHRES is a quality call, surely? If 15ms is too sloppy for a high resolution, the is should _not_ have the T_HIRES flag. So what is the minimum resolution and/or accuracy of the HIGHRES flag? | Could you please update your code according to my remarks? I will try | to integrate it into the PEP. A PEP should list all alternatives! Surely. The only updates I can see are to provide the flat interface (instead of via clock-object indirection) and the missing hires_clock() and monotonic_clock() convenience methods. A full implementation would help to decide which API is the best one. Full implementation: - define all convinience function - define all list of clocks - define flags of all clocks listed in the PEP 418: clocks used in the pseudo-code of time.steady and time.perf_counter, and maybe also time.time Victor ___ Python-Dev mailing list Python-Dev@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 Wed, Apr 4, 2012 at 9:38 AM, Cameron Simpson c...@zip.com.au wrote:
I could do this. I think I'm -0 on it, because it doesn't seem more
expressive to my eye than the straight make-a-bitmask | form.
Other opinions?
Yes. I've been mostly staying out of the PEP 418 clock discussion
(there are enough oars in there already), but numeric flags are
unnecessarily hard to debug. Use strings as your constants unless
there's a compelling reason not to.
Seeing ('MONOTONIC', 'HIGHRES') in a debugger or exception message
is a lot more informative than seeing 3.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
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 wrote: People have been saying hires throughout the threads I think, but I for one would be slightly happier with highres. hirez? -- Greg ___ Python-Dev mailing list Python-Dev@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 04/04/2012 01:04, Greg Ewing wrote: Cameron Simpson wrote: People have been saying hires throughout the threads I think, but I for one would be slightly happier with highres. hirez? IMHO still too easy to read as hires. Or is it? Bah I'm going to bed and will think about it, night all. -- Cheers. Mark Lawrence. ___ Python-Dev mailing list Python-Dev@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 04Apr2012 01:45, Victor Stinner victor.stin...@gmail.com wrote: | | get_clock() returns None if no clock has the requested flags, whereas | | I expected an exception (LookupError or NotImplementError?). | | That is deliberate. People can easily write fallback like this: | | clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC) | | Why not passing a a list of set of flags? Example: | | haypo_steady = get_clock(MONOTONIC|STEADY, STEADY, MONOTONIC, REALTIME) | # try to get a monotonic and steady clock, | # or fallback to a steady clock, | # or fallback to a monotonic clock, | # or fallback to the system clock That's interesting. Ethan Furman suggested multiple arguments to be combined, whereas yours bundles multiple search criteria in one call. While it uses a bitmask as mine does, this may get cumbersome if we went with Nick's use strings! suggestion. | haypo_perf_counter = get_clock(HIGHRES, MONOTONIC|STEADY, STEADY, | MONOTONIC, REALTIME) | # try to get a high-resolution clock | # or fallback to a monotonic and steady clock, | # or fallback to a steady clock, | # or fallback to a monotonic clock, | # or fallback to the system clock | | On Windows, haypo_steady should give GetTickCount (MONOTONIC|STEADY) | and haypo_perf_counter should give QueryPerformanceCounter | (MONOTONIC|HIGHRES). Sounds ok to me. I am not familiar with the Windows counters and am happy to take your word for it. | Hum, I'm not sure that haypo_highres uses the same clocks than | time.perf_counter() in the PEP. | | If one wants an exception it is easy to follow up with: | if not clock: | raise RunTimeError(no suitable clocks on offer on this platform) | | And if don't read the doc carefuly and forget the test, you can a | NoneType object is not callable error. Excellent! An exception either way! Win win! | | get_clock() doesn't remember if a clock works or not (if it raises an | | OSError) and does not fallback to the next clock on error. See | | pseudo-codes in the PEP 418. | | I presume the available clocks are all deduced from the platform. Your | pseudo code checks for OSError at fetch-the-clock time. I expect that | to occur once when the module is loaded, purely to populate the table | of avaiable platform clocks. | | It's better to avoid unnecessary system calls at startup (when the | time module is loaded), but you may defer the creation of the clock | list, or at least of the flags of each clock. Yes indeed. I think this should be deferred until use. | Note that you don't need to provide a clock list at all; get_clock(0 | will use ALL_CLOCKS by default, and hires() and monotonic() should each | have their own default list. | | A list of clocks and a function are maybe redundant. Why not only | providing a function? Only because the function currently only returns one clock. The picky user may want to peruse all the clocks inspecting other metadata (precision etc) than the coarse flag requirements. There should be a way to enumerate the available clock implementation; in my other recent post I suggest either lists (as current), a get_clocks() function, or a mode parameter to get_clock() such as _all_clocks, defaulting to False. | Regarding the choice itself: as the _caller_ (not the library author), | you must decide what you want most. You're already planning offering | monotonic() and hires() calls without my proposal! | | My PEP starts with use cases: it proposes one clock per use case. | There is no If you need a monotonic, steady and high-resolution clock | ... use case. Yes. but this is my exact objection to the just provide hires() and steady() and/or monotonic() API; the discussion to date is littered with I can't imagine wanting to do X style remarks. We should not be trying to enumerate the user case space exhaustively. I'm entirely in favour of your list of use cases and the approach of providing hires() et al to cover the thought-common use cases. But I feel we really _must_ provide a way for the user with a not-thought-of use case to make an arbitrary decision. get_clock() provides a simple cut at the gimme a suitable clock approach, with the lists or other get me an enumeration of the available clocks mechanism for totally ad hoc perusal if the need arises. This is also my perhaps unstated concern with Guido's the more I think about it, the more I believe these functions should have very loose guarantees, and instead just cater to common use cases -- availability of a timer with minimal fuss is usually more important than the guarantees http://www.mail-archive.com/python-dev@python.org/msg66173.html The easy to use hires() etc must make very loose guarentees or they will be useless too often. That looseness is fine in some ways - it provides availability on many platforms (all?) and discourages the user from hoping for too much and thus writing fragile code. But it also PREVENTS the user from obtaining a really good clock if it is available (where good
Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
I've just finished sketching out a skeleton here: https://bitbucket.org/cameron_simpson/css/src/fb476fcdcfce/lib/python/cs/clockutils.py get_clock() returns None if no clock has the requested flags, whereas I expected an exception (LookupError or NotImplementError?). get_clock() doesn't remember if a clock works or not (if it raises an OSError) and does not fallback to the next clock on error. See pseudo-codes in the PEP 418. The idea of flags attached to each clock is interesting, but I don't like the need of different list of clocks. Should I use MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and high-resolution clock? It would be simpler to have only one global and *private* list. If you have only one list of clocks, how do sort the list to get QueryPerformanceCounter when the user asks for highres and GetTickCount when the user asks for monotonic? The if clock.flags flags == flags: test in get_clock() is maybe not enough. I suppose that we would have the following flags for Windows functions: QueryPerformanceCounter.flags = T_HIRES GetTickCount.flags = T_MONOTONIC | T_STEADY (or maybe QueryPerformanceCounter.flags = T_HIRES | T_MONOTONIC ?) monotonic_clock() should maybe try to get a clock using the following list of conditions: - T_MONOTONIC | T_STEADY - T_MONOTONIC | T_HIGHRES - T_MONOTONIC The T_HIGHRES flag in unclear, even in the PEP. According to the PEP, any monotonic clock is considered as a high-resolution clock. Do you agree? So we would have: GetTickCount.flags = T_MONOTONIC | T_STEADY | T_HIGHRES Even if GetTickCount has only an accuracy of 15 ms :-/ Can list please give the list of flags of each clocks listed in the PEP? Only clocks used for time.time, time.monotonic and time.highres (not process and thread clocks nor QueryUnbiasedInterruptTime). # get a clock object - often a singleton under the hood T = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_STEADY|T_HIRES) # what kind of clock did I get? print T.flags # get the current time now = T.now The API looks much more complex than the API proposed in PEP 418 just to get the time. You have to call a function to get a function, and then call the function, instead of just calling a function directly. Instead of returning an object with a now() method, I would prefer to get directly the function getting time, and another function to get metadata of the clock. This removes policy from the library functions and makes it both simple and obvious in the user's calling code, and also makes it possible for the user to inspect the clock and find out what quality/flavour of clock they got. I'm not sure that users understand correctly differences between all these clocks and are able to use your API correctly. How should I combinese these 3 flags (T_HIRES, T_MONOTONIC and T_STEADY)? Can I use any combinaison? Which flags are portable? Or should I always use an explicit fallback to ensure getting a clock on any platform? Could you please update your code according to my remarks? I will try to integrate it into the PEP. A PEP should list all alternatives! Victor ___ Python-Dev mailing list Python-Dev@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 02Apr2012 13:37, Victor Stinner victor.stin...@gmail.com wrote: | I've just finished sketching out a skeleton here: | https://bitbucket.org/cameron_simpson/css/src/fb476fcdcfce/lib/python/cs/clockutils.py | | get_clock() returns None if no clock has the requested flags, whereas | I expected an exception (LookupError or NotImplementError?). That is deliberate. People can easily write fallback like this: clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC) With exceptions one gets a complicated try/except/else chain that is much harder to read. With a second fallback the try/except gets even worse. If one wants an exception it is easy to follow up with: if not clock: raise RunTimeError(no suitable clocks on offer on this platform) | get_clock() doesn't remember if a clock works or not (if it raises an | OSError) and does not fallback to the next clock on error. See | pseudo-codes in the PEP 418. I presume the available clocks are all deduced from the platform. Your pseudo code checks for OSError at fetch-the-clock time. I expect that to occur once when the module is loaded, purely to populate the table of avaiable platform clocks. If you are concerned about clocks being available/unavailable at different times (unplugging the GPS peripheral? just guessing here) that will have to raise OSError during the now() call (assuming the clock even exposes the failure; IMO it should when now() is called). | The idea of flags attached to each clock is interesting, but I don't | like the need of different list of clocks. There's no need, just quality of implementation for the monotonic()/hires() convenience calls, which express the (hoped to be common) policy of what clock to offer for each. We've just had pages upon pages of discussion about what clock to offer for the rather bald monotonic() (et al) calls. The ordering of the MONTONIC_CLOCKS list would express the result of that discussion, in that the better clocks come first. | Should I use | MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and | high-resolution clock? Note that you don't need to provide a clock list at all; get_clock(0 will use ALL_CLOCKS by default, and hires() and monotonic() should each have their own default list. I'll put in montonic() and montonic_clock(clocklist=MONOTONIC_CLOCKS) into the skeleton to make this clear; I see I've omitted them. Regarding the choice itself: as the _caller_ (not the library author), you must decide what you want most. You're already planning offering monotonic() and hires() calls without my proposal! Taking your query Should I use MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and high-resolution clock is _already_ a problem. Of course you must call monotonic() or hires() first under the current scheme, and must answer this question anyway. Do you prefer hires? Use it first! No preference? Then the question does not matter. If I, as the caller, have a preference then it is obvious what to use. If I do not have a preference then I can just call get_clock() with both flags and then arbitrarily fall back to hires() or monotonic() if that does not work. | It would be simpler to have only one global and | *private* list. No. No no no no no! The whole point is to let the user be _able_ to control the choices to a fair degree without platform special knowledge. The lists are deliberately _optional_ parameters and anyway hidden in the hires() and monotonic() convenince functions; the user does not need to care about them. But the picky user may! The lists align exactly one to one with the feature flags, so there is no special knowledge present here that is not already implicit in publishing the feature flags. | If you have only one list of clocks, how do sort the list to get | QueryPerformanceCounter when the user asks for highres and | GetTickCount when the user asks for monotonic? This is exactly why there are supposed to be different lists. You have just argued against your objection above. | The if clock.flags | flags == flags: test in get_clock() is maybe not enough. I suppose | that we would have the following flags for Windows functions: | | QueryPerformanceCounter.flags = T_HIRES | GetTickCount.flags = T_MONOTONIC | T_STEADY | | (or maybe QueryPerformanceCounter.flags = T_HIRES | T_MONOTONIC ?) Obviously these depend on the clock characteristics. Is QueryPerformanceCounter monotonic? | monotonic_clock() should maybe try to get a clock using the following | list of conditions: | - T_MONOTONIC | T_STEADY | - T_MONOTONIC | T_HIGHRES | - T_MONOTONIC Sure, seems reasonable. That is library internal policy _for the convenince monotonic() function()_. | The T_HIGHRES flag in unclear, even in the PEP. According to the PEP, | any monotonic clock is considered as a high-resolution clock. Do you | agree? Not particularly. I easily can imagine a clock with one second resolution hich was monotonic. I would not expect it to have the
Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
On 03Apr2012 07:38, I wrote: | On 02Apr2012 13:37, Victor Stinner victor.stin...@gmail.com wrote: | | Could you please update your code according to my remarks? I will try | | to integrate it into the PEP. A PEP should list all alternatives! New code here: https://bitbucket.org/cameron_simpson/css/src/91848af8663b/lib/python/cs/clockutils.py Diff: https://bitbucket.org/cameron_simpson/css/changeset/91848af8663b Changelog: updates based on suggestions from Victor Stinner: flat API calls to get time directly, make now() a method instead of a property, default flags for get_clock(), adjust hr_clock() to hires_clock(0 for consistency. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Q: How does a hacker fix a function which doesn't work for all of the elements in its domain? A: He changes the domain. - Rich Wareham rj...@hermes.cam.ac.uk ___ 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 03Apr2012 07:38, I wrote: | On 02Apr2012 13:37, Victor Stinner victor.stin...@gmail.com wrote: | | Should I use | | MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and | | high-resolution clock? | | Note that you don't need to provide a clock list at all; get_clock(0 | will use ALL_CLOCKS by default, and hires() and monotonic() should each | have their own default list. [...] | | It would be simpler to have only one global and | | *private* list. [...] | The whole point is to let the user be _able_ to control the choices to a | fair degree without platform special knowledge. On some reflection I may lean a little more Victor's way here: I am still very much of the opinion that there should be multiple clock lists so that hires() can offer the better hires clocks first and so forth. However, perhaps I misunderstood and he was asking if he needed to name a list to get a hires clock etc. This intent is not to need to, via the convenience functions. Accordingly, maybe the list names needn't be published, and may complicate the published interface even though they're one to one with the flags. It would certainly up the ante slightly f we added more flags some time later. (For example, I think any synthetic clocks such as the caching example in the skeleton should probably have a SYNTHETIC flag. You might never ask for it, but you should be able to check for it. (I personally suspect some of the OS clocks are themselves synthetic, but no matter...) The flip side of this of course is that if the list names are private then the get_clock() and hires() etc functions almost mandatorially need the optional all_clocks=False parameter mooted in a sibling post; the really picky user needs a way to iterate over the available clocks to make a fine grained decision. On example would be to ask for monotonic clocks but omit synthetic ones (there's a synthetic clock in the skeleton though I don't partiularly expect one in reality - that really is better in a broader *utils module; I also do NOT want to get into complicated parameters to say these flags but not _those_ flags and so forth for other metadata. And again, an external module offering synthetic clocks could easily want to be able to fetch the existing and augument the list with its own, then use that with the get_clock() interfaces. So in short I think: - there should be, internally at least, multiple lists for quality of returned result - there should be a way to iterate over the available clocks, probably via an all_clocks paramater instead of a public list name Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ There is hopeful symbolism in the fact that flags do not wave in a vacuum. - Arthur C. Clarke ___ Python-Dev mailing list Python-Dev@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 03Apr2012 07:51, I wrote: | Changelog: updates based on suggestions from Victor Stinner: flat API | calls to get time directly, make now() a method instead of a property, | default flags for get_clock(), adjust hr_clock() to hires_clock(0 for | consistency. BTW, I'd also happily change T_HIRES to HIRES and so forth. They're hard to type and read at present. The prefix is a hangover from old C coding habits, with no namespaces. -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ If you don't live on the edge, you're taking up too much space. - t-shirt ___ Python-Dev mailing list Python-Dev@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)
I like the aim of letting the user control what clock it get, but I find this API pretty horrible: clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC) Just my 2 groszy. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
