Re: [Python-Dev] an alternative to embedding policy in PEP 418
On Fri, Apr 6, 2012 at 23:26, Ethan Furman et...@stoneleaf.us wrote: Huh? Your point is that all APIs are less than ideal because you have to read the docs to know for certain how they work? No. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] an alternative to embedding policy in PEP 418
Cameron Simpson wrote: On 05Apr2012 08:50, Steven D'Aprano st...@pearwood.info wrote: | Although I don't like the get_clock() API, I don't think this argument against | it is a good one. Just to divert briefly; you said in another post you didn't like the API and (also/because?) it didn't help discoverability. My core objective was to allow users to query for clocks, and ideally enumerate and inspect all clocks. Without the caller having platform specific knowledge. Clocks *are* platform specific -- not just in their availability, but also in the fine details of their semantics and behaviour. I don't think we can or should try to gloss over this. If people are making decisions about timers without knowledge of what their platform supports, they're probably making poor decisions. Even the venerable time.time() and time.clock() differ between Linux and Windows. Allowing for the sake of discussion that this is desirable, what would you propose as an API instead of get_clock() (and its friend, get_clocks() for enumeration, that I should stuff into the code). The old ways are the best. We don't have math.get_trig() and math.get_trigs() functions for querying trigonometric functions, we just expose the functions directly. I think the way to enumerate and inspect all clocks is with the tried and true Python introspection tools that people use on all other functions: * use dir(time) to see a list of names available in the module * use help(time) to read their help * read the Fine Manual to find out more * use try... except... to detect the existence of a clock There's nothing special about clocks that needs anything more than this. get_clock() looks like a factory function, but it actually isn't. It just selects from a small number of pre-existing clocks. We should just expose those pre-existing clocks directly. I don't see any advantage in adding that extra level of indirection or the addition of all this complexity: * a function get_clock() to select a clock * a function get_clocks() to enumerate all the clocks * another function for querying the properties of a clock All those functions accomplish is to increase the complexity of the API, the documentation and the implementation. It's one more special case for the user to learn: To find out what functions are available, use dir(module), except for clocks, where you have to use time.get_clocks(). Blah. Another problem with get_clock() -- it will be an attractive nuisance for the sort of person who cares about symmetry and completeness. You will have a steady trickle of feature requests from users who are surprised that not every combination of features is supported. Out of the eight or sixteen or thirty-two potential clocks that get_clock() tempts the user with, only three or five will actually exist. The only advantage of get_clock is that you don't need to know the *name* of a platform clock in order to use it, you can describe it with a series of flags or enums. But in practice, that's not an advantage, that's actually a disadvantage. Consider: Which clock should I use for such-and-such a task, foo or bar? versus Which clock should I use for such-and-such a task, get_clock(spam, eggs, cheese) or get_clock(ham, eggs, truffles)? The mere mechanics of talking about these clocks will suffer because they aren't named. -- Steven ___ Python-Dev mailing list Python-Dev@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 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
On Fri, Apr 06, 2012 at 11:57:20AM +0900, Stephen J. Turnbull step...@xemacs.org wrote: What I want to know is why you're willing to assert that absence of a clock of a particular configuration is an Exception, when that absence clearly documented to be a common case? An error or not an error depends on how people will use the API. I usually don't like error codes -- people tend to ignore them or check lazily. If some library would do (get_clock(THIS) or get_clock(THAT)).clock() I want to get a clearly defined and documented clock-related error, not some vague AttributeError: 'NoneType' object has no attribute 'clock'. Oleg. -- Oleg 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
Oleg Broytman wrote: On Fri, Apr 06, 2012 at 11:57:20AM +0900, Stephen J. Turnbull step...@xemacs.org wrote: What I want to know is why you're willing to assert that absence of a clock of a particular configuration is an Exception, when that absence clearly documented to be a common case? An error or not an error depends on how people will use the API. I usually don't like error codes -- people tend to ignore them or check lazily. If some library would do (get_clock(THIS) or get_clock(THAT)).clock() I want to get a clearly defined and documented clock-related error, not some vague AttributeError: 'NoneType' object has no attribute 'clock'. The error won't be that vague -- it will include that offending line, making the problem easy to track. ~Ethan~ ___ Python-Dev mailing list Python-Dev@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 Fri, Apr 6, 2012 at 00:17, Cameron Simpson c...@zip.com.au wrote: Gah! ALL functions are like that! How often do we see questions about max() or split() etc that a close reading of the docs obviate? My point exactly. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] an alternative to embedding policy in PEP 418
Lennart Regebro wrote: On Fri, Apr 6, 2012 at 00:17, Cameron Simpson c...@zip.com.au wrote: Good point, but the same does for using flags. If you don't pass in the MONOTONIC flag, what happens? Only reading the documentation will tell you. As such this, if anything, is an indication that the get_clock() API isn't ideal in any incarnation. Gah! ALL functions are like that! How often do we see questions about max() or split() etc that a close reading of the docs obviate? My point exactly. Huh? Your point is that all APIs are less than ideal because you have to read the docs to know for certain how they work? ~Ethan~ ___ Python-Dev mailing list Python-Dev@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
I don't know who started this, but the PEP 418 threads have altogether too much snarkiness and not enough content. It's bad enough that we're bikeshedding so intensely; we don't need clever comebacks in triplicate to every out-of-context argument. --Guido On Fri, Apr 6, 2012 at 2:26 PM, Ethan Furman et...@stoneleaf.us wrote: Lennart Regebro wrote: On Fri, Apr 6, 2012 at 00:17, Cameron Simpson c...@zip.com.au wrote: Good point, but the same does for using flags. If you don't pass in the MONOTONIC flag, what happens? Only reading the documentation will tell you. As such this, if anything, is an indication that the get_clock() API isn't ideal in any incarnation. Gah! ALL functions are like that! How often do we see questions about max() or split() etc that a close reading of the docs obviate? My point exactly. Huh? Your point is that all APIs are less than ideal because you have to read the docs to know for certain how they work? ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@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 20:25, Steven D'Aprano st...@pearwood.info wrote: | Cameron Simpson wrote: | My core objective was to allow users to query for clocks, and ideally | enumerate and inspect all clocks. Without the caller having platform | specific knowledge. | | Clocks *are* platform specific -- not just in their availability, but also in | the fine details of their semantics and behaviour. I don't think we can or | should try to gloss over this. This is why get_clock() returns a clock object, which can have metadata exposing such details. Up to and including the name of the platform specific library/system-call at its core. The issue with monotonic() on its own is that the guarentees in the doco will have to be fairly loose. That prevents the user learning about fine details of their semantics and behaviour. Glossing over this stuff is exactly what offering _only_ a few genericly characterised clock names (monotonic() et al) does. | If people are making decisions about timers | without knowledge of what their platform supports, they're probably making | poor decisions. Even the venerable time.time() and time.clock() differ between | Linux and Windows. time.clock() does, as (you?) clearly demonstrated elsewhere. time.time()? (Aside from precision?) | Allowing for the sake of discussion that this is desirable, what would | you propose as an API instead of get_clock() (and its friend, get_clocks() | for enumeration, that I should stuff into the code). | | The old ways are the best. We don't have math.get_trig() and math.get_trigs() | functions for querying trigonometric functions, we just expose the functions | directly. | | I think the way to enumerate and inspect all clocks is with the tried and true | Python introspection tools that people use on all other functions: | | * use dir(time) to see a list of names available in the module So, they see monotonic. Does that tell them much about fine details? | * use help(time) to read their help Useful only to humans, not programs. | * read the Fine Manual to find out more Useful only to humans, not programs. | * use try... except... to detect the existence of a clock Useful only for a fixed list of defined name. Works fine for monotonic, highres, steady or whatever. And I would be ok with the module presenting these only where available and concealing them otherwise, thus raising AttributeError. Or ImportError (from time import monotonic). | There's nothing special about clocks that needs anything more than this. This I think is false. In fact, I think your own statement at the start about glossing over fine details goes against this. If I ask for a highres clock, I might well care _how_ precise it was. If I ask for a steady clock, I might well care how large its slews were. If I ask for a monotonic clock, I might well want to know if it tracks wall clock time (even if by magic) or elapsed system run time (eg time that stops increasing if the system is suspended, whereas wallclocks do not). Example: a wallclock is nice for log timestamps. A system run time clock is nice for profiling. They're both monotonic in some domain. | get_clock() looks like a factory function, but it actually isn't. It just | selects from a small number of pre-existing clocks. That number may still be a few. Victor's made it clear that Windows has a choice of possible highres clocks, UNIX clock_getres() offers several possible clock behaviours and an indication that a platform may have several clocks embodying a subset of these, and may indeed offer more clocks. | We should just expose | those pre-existing clocks directly. But exposing them _purely_ _by_ _name_ means inventing names for every single platform clock, and knowing those names per platform. time.clock() is a fine example where the name tells you nearly nothing about the clock behaviour. If the user cares about fine detail as you suggest they need to know their platform and have _external_ knowledge of the platform specifics; they can't inspect from inside the program. | I don't see any advantage in adding that | extra level of indirection or the addition of all this complexity: | * a function get_clock() to select a clock | * a function get_clocks() to enumerate all the clocks These are only two functions because the next alternative seemed an all_clocks= mode parameter, which changed the signature of the function return. Another alternative is the public lists-of-clocks. The point it to be able to enumerate all available clocks for consideration of their properties; get_clock() provides a simple way to coarsely say a clock like _this_ for the common instances of this. | * another function for querying the properties of a clock No, that's why you get a clock object back. You can examine it directly for defined metadata names (epoch, precision, underlying-os-clock-name, etc). In exactly the fashion you appear to want for the top level offerings: by knowing the metadata property
Re: [Python-Dev] an alternative to embedding policy in PEP 418
On 4/6/2012 4:11 PM, Cameron Simpson wrote: Another alternative is the public lists-of-clocks. After watching this thread with amusement and frustration, amusement because it is so big, and so many people have so many different opinions, frustration, because it seems that few of the clocks that are available are anywhere near ideal for any particular stated characteristic, and because none of the APIs presented provide a way for the user to specify the details of the characteristics of the desired clock, I think this idea of a list-of-clocks sounds better and better. Hopefully, for each system, the characteristics of each clock can be discovered, and fully characterized in available metadata for the clock... tick rate, or list of tick rates maximum variation of tick rate precision maximum helicopter drop jump delta monotonicity frequency of rollover or None base epoch value or None behavior during system sleep, hibernate, suspend, shutdown, battery failure, flood, wartime events, and acts of God. These last two may have values that are long prose texts full of political or religious rhetoric, such as the content of this thread :) any other characteristics I forgot to mention Of course, it is not clear that all of these characteristics can be determined based on OS/Version; hardware vendors may have different implementations. There should be a way to add new clock objects to the list, given a set of characteristics, and an API to retrieve them, at least by installing a submodule that provides access to an additional clock. ___ 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 17:30, Glenn Linderman v+pyt...@g.nevcal.com wrote: | On 4/6/2012 4:11 PM, Cameron Simpson wrote: | Another alternative is the public lists-of-clocks. | | After watching this thread with amusement and frustration, amusement | because it is so big, and so many people have so many different | opinions, frustration, because it seems that few of the clocks that are | available are anywhere near ideal for any particular stated | characteristic, My partner has occasionally opined that most Prolog programs simply result in *** NO ***. We could optimise for that and simplify the implementation enormously. It would also let us provide very strong guarrentees about the offered clocks on the basis that no suitable clock would ever provided:-) | and because none of the APIs presented provide a way for | the user to specify the details of the characteristics of the desired | clock, I think this idea of a list-of-clocks sounds better and better. | | Hopefully, for each system, the characteristics of each clock can be | discovered, and fully characterized in available metadata for the clock... Victor has asked me to do that for my skeleton, based on the tables he has assembled. I'll see what i can do there... | Of course, it is not clear that all of these characteristics can be | determined based on OS/Version; hardware vendors may have different | implementations. If you can look up the kernel revision you can do fairly well. In principle. | There should be a way to add new clock objects to the list, given a set | of characteristics, and an API to retrieve them, at least by installing | a submodule that provides access to an additional clock. Returning to seriousness, the get_clock() call admits a clocklist. -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Principles have no real force except when one is well fed. - Mark Twain ___ Python-Dev mailing list Python-Dev@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] 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
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] 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] 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] 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] 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
On Wed, 4 Apr 2012 02:02:12 +0200 Victor Stinner victor.stin...@gmail.com wrote: Lennart Regebro wrote: Well, get_clock(monotonic=True, highres=True) would be a vast improvement over get_clock(MONOTONIC|HIRES). I don't like this keyword API because you have to use a magically marker (True). Why True? What happens if I call get_clock(monotonic=False) or get_clock(monotonic=yes)? Since when are booleans magical? Has this thread gone totally insane? Regards Antoine. ___ Python-Dev mailing list Python-Dev@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
2012/4/4 Antoine Pitrou solip...@pitrou.net: On Wed, 4 Apr 2012 02:02:12 +0200 Victor Stinner victor.stin...@gmail.com wrote: Lennart Regebro wrote: Well, get_clock(monotonic=True, highres=True) would be a vast improvement over get_clock(MONOTONIC|HIRES). I don't like this keyword API because you have to use a magically marker (True). Why True? What happens if I call get_clock(monotonic=False) or get_clock(monotonic=yes)? Since when are booleans magical? Has this thread gone totally insane? It depends if the option supports other values. But as I understood, the keyword value must always be True. Victor ___ Python-Dev mailing list Python-Dev@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 Wed, Apr 4, 2012 at 9:04 PM, Victor Stinner victor.stin...@gmail.com wrote: 2012/4/4 Antoine Pitrou solip...@pitrou.net: On Wed, 4 Apr 2012 02:02:12 +0200 Victor Stinner victor.stin...@gmail.com wrote: Lennart Regebro wrote: Well, get_clock(monotonic=True, highres=True) would be a vast improvement over get_clock(MONOTONIC|HIRES). I don't like this keyword API because you have to use a magically marker (True). Why True? What happens if I call get_clock(monotonic=False) or get_clock(monotonic=yes)? Since when are booleans magical? Has this thread gone totally insane? It depends if the option supports other values. But as I understood, the keyword value must always be True. If I were looking at that in documentation, my automatic guess would be that the only thing that matters is whether the argument compares-as-true or not. So get_clock(monotonic=yes) would be the same as =True, and =False wouldn't be. And get_clock(monotonic=No, you idiot, I want one that ISN'T) would... be stupid. But it'd still function :) Chris Angelico ___ Python-Dev mailing list Python-Dev@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 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. //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)
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
Oleg Broytman wrote:
On Wed, Apr 04, 2012 at 11:03:02AM -0700, Ethan Furman wrote:
Oleg Broytman wrote:
. Pythonic equivalent of get_clock(THIS) or get_clok(THAT) is
for flag in (THIS, THAT):
try:
clock = get_clock(flag)
except:
pass
else:
break
else:
raise ValueError('Cannot get clock, tried THIS and THAT')
Wow -- you'd rather write nine lines of code instead of three?
clock = get_clock(THIS) or get_clock(THAT)
if clock is None:
raise ValueError('Cannot get clock, tried THIS and THAT')
Yes - to force people to write the last two lines. Without forcing
most programmers will skip them.
You're not my real Dad! You can't tell me what to do!
*wink*
This level of paternalism is unnecessary. It's not your job to force
programmers to do anything. If people skip the test for None, they will get an
exception as soon as they try to use None as an exception, and then they will
fix their broken code.
Although I don't like the get_clock() API, I don't think this argument against
it is a good one. Exceptions are the *usual* error-handling mechanism in
Python, but they are not the *only* mechanism, there are others, and it is
perfectly okay to use non-exception based failures when appropriate. This is
one such example.
Return None on failure is how re.match() and re.search() work, and it is a
good design for when you have multiple fallbacks on failure.
result = re.match(spam, s) or re.match(ham, s) or re.match(eggs, s)
if result is None:
raise ValueError('could not find spam, ham or eggs')
This is a *much* better design than nested tries:
try:
result = re.match(spam, s)
except ValueError:
try:
result = re.match(ham, s)
except ValueError:
try:
result = re.match(eggs, s)
except ValueError:
raise ValueError('could not find spam, ham or eggs')
Wow. Now *that* is ugly code. There's nothing elegant or Pythonic about being
forced to write that out of a misplaced sense of purity.
--
Steven
___
Python-Dev mailing list
Python-Dev@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
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.) 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
On 05Apr2012 08:50, Steven D'Aprano st...@pearwood.info wrote: | Although I don't like the get_clock() API, I don't think this argument against | it is a good one. Just to divert briefly; you said in another post you didn't like the API and (also/because?) it didn't help discoverability. My core objective was to allow users to query for clocks, and ideally enumerate and inspect all clocks. Without the caller having platform specific knowledge. Allowing for the sake of discussion that this is desirable, what would you propose as an API instead of get_clock() (and its friend, get_clocks() for enumeration, that I should stuff into the code). Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Q: How many user support people does it take to change a light bulb? A: We have an exact copy of the light bulb here and it seems to be working fine. Can you tell me what kind of system you have? ___ Python-Dev mailing list Python-Dev@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
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). I also think it should raise an error if not found. The clarity and easy of use of the API is much more important than how much you can do in one line. That's a matter of opinion. I'm not particularly fond of this get_clock idea, but of the two examples given, I much prefer the first of these: get_clock(MONOTONIC|HIRES) get_clock(monotonic=True, highres=True) and not just because it is shorter. The API is crying out for enum arguments, not a series of named flags. But frankly I think this get_clock API sucks. At some earlier part of this thread, somebody listed three or four potential characteristics of clocks. If we offer these as parameters to get_clock(), that means there's eight or sixteen different clocks that the user can potentially ask for. Do we really offer sixteen different clocks? Or even eight? I doubt it -- there's probably only two or three. So the majority of potential clocks don't exist. With get_clock, discoverability is hurt. How does the caller know what clocks are available? How can she look for documentation for them? A simple, obvious, discoverable API is best. If we offer three clocks, we have three named functions. If some of these clocks aren't available on some platform, and we can't emulate them, then simply don't have that named function available on that platform. That's easy to discover: trying to use that clock will give a NameError or AttributeError, and the caller can then fall back on an alternative, or fail, whichever is appropriate. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] an alternative to embedding policy in PEP 418
Lennart Regebro wrote: Well, get_clock(monotonic=True, highres=True) would be a vast improvement over get_clock(MONOTONIC|HIRES). I don't like this keyword API because you have to use a magically marker (True). Why True? What happens if I call get_clock(monotonic=False) or get_clock(monotonic=yes)? Victor ___ Python-Dev mailing list Python-Dev@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
On 04Apr2012 09:53, Steven D'Aprano st...@pearwood.info 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).[...] | | That's a matter of opinion. I'm not particularly fond of this get_clock idea, | but of the two examples given, I much prefer the first of these: | | get_clock(MONOTONIC|HIRES) | get_clock(monotonic=True, highres=True) | | and not just because it is shorter. The API is crying out for enum arguments, | not a series of named flags. Enums would be ok with me. I went with a bitmask because it is natural to me and very simple. But anything symbolicly expression will do. | But frankly I think this get_clock API sucks. At some earlier part of this | thread, somebody listed three or four potential characteristics of clocks. If | we offer these as parameters to get_clock(), that means there's eight or | sixteen different clocks that the user can potentially ask for. Do we really | offer sixteen different clocks? Or even eight? I doubt it -- there's probably | only two or three. So the majority of potential clocks don't exist. That's not the point. I think we should offer all the platform system clocks, suitably described. That there are up to 8 or 16 flag combinations is irrelevant; no user is going to try them all. A user will have requirements for their clock. They ask for them either blandly via get_clock() or (for example considering monotonic most important) via monotonic_clock(). In the latter case, the supported clocks can be considered in a more apt order via a different internal clock list. | With get_clock, discoverability is hurt. No, because the other calls still exist. (In my proposal. I see Victor's characterised this as either/or in the PEP, never my intent.) | How does the caller know what clocks | are available? I would definitely want either: - the module clock lists available via public names, for example as in my sample clockutils.py code (ALL_CLOCKS, MONTONIC_CLOCKS etc) or via some map (eg clocks['monotonic']). - a get_clocks() function to return matching clocks, like get_clock() but not stopping on the first match - an all_clocks=False parameter to get_clock() to get an iterable of the suitable clocks | How can she look for documentation for them? There is good text in the PEP. That could be easily moved into the module doco in a clocks section. Since my clocks proposal wraps clocks in an object, they _can_ have nice class names and good docstrings and more metadata in the object (possibilities including .epoch, .precision, .is_steady() methods, .os_clock_name (eg QueryPerformanceCounter), etc). | A simple, obvious, discoverable API is best. If we offer three clocks, we have | three named functions. If some of these clocks aren't available on some | platform, and we can't emulate them, then simply don't have that named | function available on that platform. That's easy to discover: trying to use | that clock will give a NameError or AttributeError, and the caller can then | fall back on an alternative, or fail, whichever is appropriate. And I hate this. Because many platforms offer several OS clocks. The time module SHOULD NOT dictate what clocks you get to play with, and you should not need to have platform specific knowledge to look for a clock with your desired characteristics. If you just want montonic() and trust the module authors' policy decisions you can go with monotonic(), have it do AttributeError if unavailable and never worry about discoverability or the inspectable object layer. Many will probaby be happy with that. But without get_clock() or something like it, there is no discoverability and not ability for a user to decide their own clock choice policy. -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Your modesty is typically human, so I will overlook it. - a Klingon ___ Python-Dev mailing list Python-Dev@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
On 4/2/2012 4:37 AM, Victor Stinner wrote: The API looks much more complex than the API proposed in PEP 418 just to get the time. You have to call a function to get a function, and then call the function, instead of just calling a function directly. Instead of returning an object with a now() method, I would prefer to get directly the function getting time, and another function to get metadata of the clock. If there are more than two clocks, with different characteristics, no API is going to be both simple to use and fast to call. If there are more than two clocks, with different characteristics, then having an API to get the right API to call to get a time seems very natural to me. One thing I don't like about the idea of fallback being buried under some API is that the efficiency of that API on each call must be less than the efficiency of directly calling an API to get a single clock's time. For frequently called high resolution clocks, this is more burdensome than infrequently called clocks yet those seem to be the ones for which fallbacks are proposed, because of potential unavailability. Having properties on each of various different clock functions is cumbersome... the user code must know about each clock, how to obtain the properties, and then how to choose one for use... And how will one be chosen for use? Under the assumption that all return some sort of timestamp and take no parameters, a local name will be assigned to the clock of interest: if ...: myTime = os.monotonous elif ...: myTime = os.evenhigherres ... elif ...: myTime = time. time so that myTime can be use throughout. Cameron's API hides all the names of the clocks, and instead offers to do the conditional logic for you, and the resultant API returned can be directly assigned to myTime, and the logic for choosing a clock deals only with the properties of the clock, not the names of the APIs, which is a nice abstraction. There would not even be a need to document the actual names of the APIs for each individual clock, except that probably some folks would want to directly code them, especially if they are not interested in cross-platform work. The only thing I'm not so sure about: can the properties be described by flags? Might it not be better to have an API that allows specification of minimum resolution, in terms of fractional seconds? Perhaps other properties suffice as flags, but perhaps not resolution. ___ 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
On 02Apr2012 10:44, Glenn Linderman v+pyt...@g.nevcal.com wrote: | On 4/2/2012 4:37 AM, Victor Stinner wrote: | The API looks much more complex than the API proposed in PEP 418 just | to get the time. You have to call a function to get a function, and | then call the function, instead of just calling a function directly. | | Instead of returning an object with a now() method, I would prefer to | get directly the function getting time, and another function to get | metadata of the clock. | | If there are more than two clocks, with different characteristics, no | API is going to be both simple to use and fast to call. | | If there are more than two clocks, with different characteristics, then | having an API to get the right API to call to get a time seems very | natural to me. It is, though Victor's point about offering the very easy to use API is valid. The new code has the flat monotonic() et al calls as well. | One thing I don't like about the idea of fallback being buried under | some API is that the efficiency of that API on each call must be less | than the efficiency of directly calling an API to get a single clock's | time. For frequently called high resolution clocks, this is more | burdensome than infrequently called clocks yet those seem to be the | ones for which fallbacks are proposed, because of potential unavailability. I hadn't thought about that, but it isn't actually a big deal. The overhead isn't zero, but in order to always use the _same_ clock to return hires() (for example) the library has to cache the clock lookup anyway. Current clockutils.py skeleton here: https://bitbucket.org/cameron_simpson/css/src/91848af8663b/lib/python/cs/clockutils.py does so. | The only thing I'm not so sure about: can the properties be described by | flags? Might it not be better to have an API that allows specification | of minimum resolution, in terms of fractional seconds? Perhaps other | properties suffice as flags, but perhaps not resolution. It sounds nice, but there are some difficulties. Firstly, the (currently just 3) flags were chosen to map to the three features sought (in various cobinations) for clocks. Once you start requesting precision (a totally reasonable desire, BTW) you also want to request degree of slew (since steady is a tunabe term) and so forth. And what for clocks that have variable precision (I'm imaging here a clock which really is a float, and for large times (in the far future) can't return the sane resolution because of the size of a float. The concern is valid though. I could imagine beefing up the clock object metadata with .epoch (can be None!), precision (function of float width versus clock return value epislon), epsilon (your fraction of a second parameter). Of course, for some clocks any of these might be None. Then the truly concerned user iterates over the available clocks with the desired coarse flags, inspecting each closely for precision or whatever. Easy enough to tweak get_clock() to take an optional all_clocks=False parameter to return all matching clocks in an iterable instead of (the first match or None). Or the user could reach directly for one of the clock lists. cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Craft, n. A fool's substitute for brains. - The Devil's Dictionary ___ Python-Dev mailing list Python-Dev@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
On Tue, Apr 3, 2012 at 3:44 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote: One thing I don't like about the idea of fallback being buried under some API is that the efficiency of that API on each call must be less than the efficiency of directly calling an API to get a single clock's time. No, that's a misunderstanding of the fallback mechanism. The fallback happens when the time module is initialised, not on every call. Once the appropriate clock has been selected during module initialisation, it is invoked directly at call time. Cheers, Nick. -- Nick Coghlan | 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
On 4/2/2012 2:40 PM, Nick Coghlan wrote: On Tue, Apr 3, 2012 at 3:44 AM, Glenn Lindermanv+pyt...@g.nevcal.com wrote: One thing I don't like about the idea of fallback being buried under some API is that the efficiency of that API on each call must be less than the efficiency of directly calling an API to get a single clock's time. No, that's a misunderstanding of the fallback mechanism. The fallback happens when the time module is initialised, not on every call. Once the appropriate clock has been selected during module initialisation, it is invoked directly at call time. Nick, I would hope that is how the fallback mechanism would be coded, but I'm pretty sure I've seen other comments in this thread that implied otherwise. But please don't ask me to find them, this thread is huge. Glenn ___ 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
On 02Apr2012 14:59, Glenn Linderman v+pyt...@g.nevcal.com wrote: | On 4/2/2012 2:40 PM, Nick Coghlan wrote: | On Tue, Apr 3, 2012 at 3:44 AM, Glenn Lindermanv+pyt...@g.nevcal.com wrote: |One thing I don't like about the idea of fallback being buried under some |API is that the efficiency of that API on each call must be less than the |efficiency of directly calling an API to get a single clock's time. | No, that's a misunderstanding of the fallback mechanism. The fallback | happens when the time module is initialised, not on every call. Once | the appropriate clock has been selected during module initialisation, | it is invoked directly at call time. | | I would hope that is how the fallback mechanism would be coded, but I'm | pretty sure I've seen other comments in this thread that implied | otherwise. But please don't ask me to find them, this thread is huge. The idea of falling back to different clocks on the fly on different calls got a bit of a rejection I thought. A recipe for clock inconsitency whatever the failings of the current clock. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ We need a taxonomy for 'printing-that-is-no-longer-printing.' - overhead by WIRED at the Intelligent Printing conference Oct2006 ___ Python-Dev mailing list Python-Dev@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
[Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
On 28Mar2012 23:40, Victor Stinner victor.stin...@gmail.com wrote: | Does this primarily give a high resolution clock, or primarily a | monotonic clock? That's not clear from either the name, or the PEP. | | I expect a better resolution from time.monotonic() than time.time(). I | don't have exact numbers right now, but I began to document each OS | clock in the PEP. I wish to raise an alternative to these set-in-stone policy-in-the-library choices, and an alternative to any proposal that does fallback in a function whose name suggests otherwise. Off in another thread on PEP 418 I suggested a cleaner approach to offering clocks to the user: let the user ask! My (just two!) posts on this are here: http://www.mail-archive.com/python-dev@python.org/msg66174.html http://www.mail-archive.com/python-dev@python.org/msg66179.html The second post is more important as it fleshes out my reasons for considering this appraoch better. I've just finished sketching out a skeleton here: https://bitbucket.org/cameron_simpson/css/src/fb476fcdcfce/lib/python/cs/clockutils.py In short: - take Victor's hard work on system clocks and classifying thm by feature set - tabulate access to them in a list of clock objects - base access class goes (example user call): # get a clock object - often a singleton under the hood T = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_STEADY|T_HIRES) # what kind of clock did I get? print T.flags # get the current time now = T.now - offer monotonic() and/or steady() etc as convenience functions calling get_clock() in a fashion like the above example - don't try to guess the user's use case ahead of time This removes policy from the library functions and makes it both simple and obvious in the user's calling code, and also makes it possible for the user to inspect the clock and find out what quality/flavour of clock they got. Please have a glance through the code, especially the top and botth bits; it is only 89 lines long and includes (presently) just a simple object for time.time() and (importantly for the bikeshedding) an example synthetic clock to give a monotonic caching clock from another non-monotonic clock (default, again, time.time() in this prototype). Suitably fleshed out with access to the various system clocks, this can offer all the current bikeshedding in a simple interface and without constraining user choices to what we thought of, or what we thought likely. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Availability: Samples Q1/97 Volume H2/97 So, it's vapor right now, but if you want to sell vapor in 1997 you better had damn fast vapor then... - Burkhard Neidecker-Lutz on the DEC Alpha 21264, October 1996 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
