On Fri, Apr 6, 2012 at 23:26, Ethan Furman 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
On 06Apr2012 17:30, Glenn Linderman 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,
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 th
On 06Apr2012 20:25, Steven D'Aprano 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 av
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 Fur
Lennart Regebro wrote:
On Fri, Apr 6, 2012 at 00:17, Cameron Simpson 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
On Fri, Apr 6, 2012 at 00:17, Cameron Simpson 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
Oleg Broytman wrote:
On Fri, Apr 06, 2012 at 11:57:20AM +0900, "Stephen J. Turnbull"
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
On Fri, Apr 06, 2012 at 11:57:20AM +0900, "Stephen J. Turnbull"
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
On Thu, Apr 5, 2012 at 21:57, Stephen J. Turnbull 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 fi
Cameron Simpson wrote:
On 05Apr2012 08:50, Steven D'Aprano 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.
On Fri, Apr 6, 2012 at 12:22 AM, Oleg Broytman wrote:
> On Thu, Apr 05, 2012 at 11:45:06PM +0900, Stephen J. Turnbull wrote:
>> On Thu, Apr 5, 2012 at 10:34 PM, Oleg Broytman wrote:
>> > Why doesn't open() return None for a non-existing file? or
>> > socket.gethostbyname() for a non-existing na
On 06Apr2012 08:51, I wrote:
| On 06Apr2012 00:27, Victor Stinner wrote:
| | By the way, I removed ("deferred") the time.highres() function from the
| | PEP,
|
| Chuckle; was not the whole PEP for a high res clock?
Gah. I see it was for montonic, not high res. Sorry.
[...]
| I can think of def
On 06Apr2012 00:27, Victor Stinner wrote:
| Le 06/04/2012 00:17, Cameron Simpson a écrit :
| > This is where the bitmap approach can be less confusing - the docstring
| > says "The returned clock shall have all the requested flags". It is at
| > least very predictable.
|
| By the way, I removed (
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
On 05Apr2012 10:21, Lennart Regebro wrote:
| On Thu, Apr 5, 2012 at 01:10, Victor Stinner wrote:
| > Ok for the default, but what happens if the caller sets an option to
| > False? Does get_clock(monotonic=False) return a non-monotonic clock?
| > (I guess no, but it may be confusing.)
This is wh
On 06Apr2012 00:15, Oleg Broytman wrote:
|So we can argue in circles both ways, there are too many arguments
| pro and contra. Python is just too inconsistent to be consistently
| argued over. ;-)
Bah! I think these threads demonstrate that we can consistently argue
over Python for weeks per
On 05Apr2012 03:05, Oleg Broytman wrote:
| On Wed, Apr 04, 2012 at 12:52:00PM -0700, Ethan Furman wrote:
| > Forced? I do not use Python to be forced to use one style of
| > programming over another.
|
|Then it's strange you are using Python with its strict syntax
| (case-sensitivity, forced
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 NotFou
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.
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,
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'.
M
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'
On Thu, 05 Apr 2012 19:22:17 +0400, Oleg Broytman wrote:
> On Thu, Apr 05, 2012 at 11:45:06PM +0900, Stephen J. Turnbull wrote:
> > On Thu, Apr 5, 2012 at 10:34 PM, Oleg Broytman wrote:
> > > Â Why doesn't open() return None for a non-existing file? or
> > > socket.gethostbyname() for a non-exis
On Thu, Apr 05, 2012 at 11:45:06PM +0900, Stephen J. Turnbull wrote:
> On Thu, Apr 5, 2012 at 10:34 PM, Oleg Broytman wrote:
> > Why doesn't open() return None for a non-existing file? or
> > socket.gethostbyname() for a non-existing name?
>
> That's not an answer to my question, because those
On Thu, Apr 5, 2012 at 10:34 PM, Oleg Broytman wrote:
> Why doesn't open() return None for a non-existing file? or
> socket.gethostbyname() for a non-existing name?
That's not an answer to my question, because those calls have very
important use cases where the user knows the object exists (an
On Thu, Apr 05, 2012 at 10:06:38PM +0900, Stephen J. Turnbull wrote:
> On Thu, Apr 5, 2012 at 8:05 AM, Oleg Broytman wrote:
> > Well, I am partially retreat. "Errors should never pass silently.
> > Unless explicitly silenced." get_clock(FLAG, on_error=None) could return
> > None.
>
> I still do
On Thu, Apr 5, 2012 at 8:05 AM, Oleg Broytman wrote:
> Well, I am partially retreat. "Errors should never pass silently.
> Unless explicitly silenced." get_clock(FLAG, on_error=None) could return
> None.
I still don't see what's erroneous about returning None when asked for
an object that is do
On Thu, Apr 5, 2012 at 01:10, Victor Stinner wrote:
> 2012/4/4 Lennart Regebro :
>> On Wed, Apr 4, 2012 at 13:04, Victor Stinner
>> wrote:
>>> It depends if the option supports other values. But as I understood,
>>> the keyword value must always be True.
>>
>> Or False, obviously. Which would al
On 05Apr2012 08:50, Steven D'Aprano 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
2012/4/4 Lennart Regebro :
> On Wed, Apr 4, 2012 at 13:04, Victor Stinner wrote:
>> It depends if the option supports other values. But as I understood,
>> the keyword value must always be True.
>
> Or False, obviously. Which would also be default.
Ok for the default, but what happens if the call
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:
> >
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
On 04Apr2012 19:47, 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 wrote:
| >>> What's unclear about returning None if no clocks match?
| >>
| >> Nothing, but having to check error values on return funct
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
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
> >
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 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 Pytho
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 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
Am 04.04.2012 18:18, schrieb Ethan Furman:
> Lennart Regebro wrote:
>> On Tue, Apr 3, 2012 at 18:07, Ethan Furman 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. Usua
On Wed, Apr 04, 2012 at 05:47:16PM +0200, Lennart Regebro wrote:
> On Tue, Apr 3, 2012 at 18:07, Ethan Furman 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, Py
Lennart Regebro wrote:
On Tue, Apr 3, 2012 at 18:07, Ethan Furman 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 do
On Tue, Apr 3, 2012 at 18:07, Ethan Furman 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
On Wed, Apr 4, 2012 at 13:04, Victor Stinner wrote:
> It depends if the option supports other values. But as I understood,
> the keyword value must always be True.
Or False, obviously. Which would also be default.
//Lennart
___
Python-Dev mailing list
On Wed, Apr 4, 2012 at 9:04 PM, Victor Stinner wrote:
> 2012/4/4 Antoine Pitrou :
>> On Wed, 4 Apr 2012 02:02:12 +0200
>> Victor Stinner wrote:
>>> > Lennart Regebro wrote:
>>> >> Well, get_clock(monotonic=True, highres=True) would be a vast
>>> >> improvement over get_clock(MONOTONIC|HIRES).
>>>
2012/4/4 Antoine Pitrou :
> On Wed, 4 Apr 2012 02:02:12 +0200
> Victor Stinner 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 mag
On Wed, 4 Apr 2012 02:02:12 +0200
Victor Stinner 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?
(Sorry, should have sent to the list).
On 4 April 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?
What's wrong with high_resolution?
Paul
_
On 04Apr2012 01:45, Victor Stinner 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_
On 04Apr2012 09:53, Steven D'Aprano wrote:
| Lennart Regebro wrote:
| > On Tue, Apr 3, 2012 at 08:03, Cameron Simpson 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?
| >
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
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/py
> 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(monoto
Lennart Regebro wrote:
On Tue, Apr 3, 2012 at 08:03, Cameron Simpson 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
im
On Wed, Apr 4, 2012 at 9:38 AM, Cameron Simpson 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
> | 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 l
On 03Apr2012 15:08, Ethan Furman 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 p
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 th
On 03Apr2012 09:07, Ethan Furman wrote:
| Lennart Regebro wrote:
| > On Tue, Apr 3, 2012 at 08:03, Cameron Simpson 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?
| >
Lennart Regebro wrote:
On Tue, Apr 3, 2012 at 08:03, Cameron Simpson 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
im
On Tue, Apr 3, 2012 at 08:03, Cameron Simpson 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_c
On 03Apr2012 09:03, Mark Lawrence wrote:
| On 03/04/2012 07:03, Cameron Simpson wrote:
| > On 03Apr2012 07:51, Lennart Regebro 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_HIRE
On 03/04/2012 07:03, Cameron Simpson wrote:
On 03Apr2012 07:51, Lennart Regebro 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 go
On 03Apr2012 07:51, Lennart Regebro 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
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://
On 02Apr2012 14:59, Glenn Linderman wrote:
| On 4/2/2012 2:40 PM, Nick Coghlan wrote:
| > On Tue, Apr 3, 2012 at 3:44 AM, Glenn Linderman
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
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_HIRE
On 4/2/2012 2:40 PM, Nick Coghlan wrote:
On Tue, Apr 3, 2012 at 3:44 AM, Glenn Linderman 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 g
On Tue, Apr 3, 2012 at 3:44 AM, Glenn Linderman 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 misunde
On 03Apr2012 07:38, I wrote:
| On 02Apr2012 13:37, Victor Stinner 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
On 02Apr2012 10:44, Glenn Linderman 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 d
On 03Apr2012 07:38, I wrote:
| On 02Apr2012 13:37, Victor Stinner 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
On 02Apr2012 13:37, Victor Stinner 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 (LookupE
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() me
> 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 re
On 28Mar2012 23:40, Victor Stinner 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, b
75 matches
Mail list logo
