Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
On Wed, Apr 04, 2012 at 03:28:34AM +0200, Victor Stinner wrote: > Le 04/04/2012 02:33, Steven D'Aprano a écrit : > >Judging by the hundreds of emails regarding PEP 418, the disagreements > >about APIs, namings, and even what characteristics clocks should have, I > >believe that the suggestion is too divisive (and confusing!) to be > >accepted or rejected at this time. > > Oh, I just "rewrote" the PEP before reading your email. Sorry for the > noise with this PEP :-) I just read again all emails related to this PEP > to complete the PEP. The PEP should now list all proposed API designs. I > hope that I did not forget anything. I think the PEP is a good, important PEP, and thank you for being the PEP's champion. But in my opinion, this is too big to rush it and risk locking in a sub-standard API for the next decade or two. > >I propose for Python 3.3: > > > >1) the os module should expose lightweight wrappers around whatever > >clocks the operating system provides; > > Python 3.3 has already time.clock_gettime() and time.clock_getres() with > CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW, CLOCK_HIGHRES. Why does it already have these things when the PEP is not accepted? (This is not a rhetorical question, perhaps there is a good reason why these have been added independently of the PEP.) If I remember correctly, Guido earlier mentioned that he only wanted to see one or two (I forget which) new clocks, and I see in 3.3.0a1 there are already at least five new clocks: monotonic or clock_gettime(CLOCK_MONOTONIC) # Are these the same thing? wallclock clock_gettime(CLOCK_PROCESS_CPUTIME_ID) clock_gettime(CLOCK_REALTIME) clock_gettime(CLOCK_THREAD_CPUTIME_ID) plus the old ways, time.time and time.clock. (Neither of which seems to have a clock-id.) > mach_absolute_time() and GetTickCount/GetTick64 are not available yet. That will make potentially 10 different clocks in the time module. It may be that, eventually, Python should support all these ten different clocks. (Personally, I doubt that the average Python programmer cares about the difference between time() and clock(), let alone another eight more.) But there's no rush. I think we should start by supporting OS-specific clocks in the os module, and then once we have some best-practice idioms, we can promote some of them to the time module. -- Steven ___ Python-Dev mailing list [email protected] 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 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 [email protected] 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 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
On Wed, 4 Apr 2012 18:09:40 +1000 Steven D'Aprano wrote: > > Python 3.3 has already time.clock_gettime() and time.clock_getres() with > > CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW, CLOCK_HIGHRES. > > Why does it already have these things when the PEP is not accepted? > > (This is not a rhetorical question, perhaps there is a good reason why > these have been added independently of the PEP.) Because these are thin (low-level) wrappers around the corresponding POSIX APIs, so there is no reason not to add them. I know you were asking for such wrappers to be in the "os" module, but my understanding is that time-related functions should preferably go into the "time" module. "os" is already full of very diverse stuff, and documentation-wise it is better if time-related functions end up in a time-related module. Otherwise we'll end up having to cross-link manually, which is always cumbersome (for us) and less practical (for the reader). Regards Antoine. ___ Python-Dev mailing list [email protected] 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 : > 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? 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
>> Why does it already have these things when the PEP is not accepted? >> ... >> (This is not a rhetorical question, perhaps there is a good reason why >> these have been added independently of the PEP.) time.clock_gettime() & friends were added by the issue #10278. The function was added before someone asked (me) to write a PEP. The need of a PEP came later, when time.wallclock() and time.monotonic() functions were added. > Because these are thin (low-level) wrappers around the corresponding > POSIX APIs, so there is no reason not to add them. time.clock_gettime() can be used for other purpose than a monotonic clock. For example, CLOCK_THREAD_CPUTIME_ID is the only available function to get the "Thread-specific CPU-time clock". It also gives access to CLOCK_MONOTONIC_RAW which is not used by the time.monotonic() function proposed in the PEP. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
> I failed to propose a consistent and clear API because I (and Guido!) wanted > to fallback to the system clock. Falling back to the system clock is a > problem when you have to define the function in the documentation or if you > don't want to use the system clock (but do something else) if no monotonic > clock is available. Well, it was not only Guido and me. Nick Coghlan wrote: "However, I think Victor's right to point out that the *standard library* needs to have a fallback to maintain backwards compatibility if time.monotonic() isn't available, and it seems silly to implement the same fallback logic in every module where we manipulate timeouts." and "Since duplicating that logic in every module that handles timeouts would be silly, it makes sense to provide an obvious way to do it in the time module." Michael Foord wrote: "It is this always-having-to-manually-fallback-depending-on-os that I was hoping your new functionality would avoid. Is time.try_monotonic() suitable for this usecase?" The following functions / libraries fall back to the system clock if no monotonic clock is available: - QElapsedTimer class of the Qt library - g_get_monotonic_time() of the glib library - monotonic_clock library - AbsoluteTime.now (third-party Ruby library), "AbsoluteTime.monotonic?" tells if AbsoluteTime.now is monotonic Extract of the glib doc: "Otherwise, we make a best effort that probably involves returning the wall clock time (with at least microsecond accuracy, subject to the limitations of the OS kernel)." -- Only the python-monotonic-time fails with an OSError if no monotonic clock is available. System.nanoTime() of Java has few garantee: "Returns the current value of the most precise available system timer, in nanoseconds. This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. The value returned represents nanoseconds since some fixed but arbitrary time (perhaps in the future, so values may be negative)." I don't even know if it is monotonic, steady or has an high resolution. Note: Boost.Chrono.high_resolution_clock falls back to the system clock if no steady clock is available. (But the high-resolution clock idea was deferred, it's something different than a monotonic or steady clock.) Victor ___ Python-Dev mailing list [email protected] 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 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). >>> >>> 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo
On Mon, Apr 2, 2012 at 08:58, Thomas Spura wrote: > On Mon, Apr 2, 2012 at 2:54 PM, Stefan Behnel wrote: > > Antoine Pitrou, 02.04.2012 13:50: > >> On Sun, 1 Apr 2012 19:44:00 -0500 > >> Brian Curtin wrote: > >>> On Sun, Apr 1, 2012 at 17:31, Matěj Cepl wrote: > On 1.4.2012 23:46, Brian Curtin wrote: > > For what reason? Are the git or bzr files causing issues on HG? > > > No, but wrong .gitignore causes issues with git repo obtained via > hg-fast-import. If it is meant as an intentional sabotage of using > git (and > bzr) for cpython, then that's the only explanation I can understand, > otherwise it doesn't make sense to me why these files are in HG > repository > at all. > >>> > >>> Then you won't understand. Sometimes things get out of date when they > >>> aren't used or maintained. > >>> > >>> You're welcome to fix the problem if you're a Git user, as suggested > earlier. > >> > >> That said, these files will always be outdated, so we might as well > >> remove them so that at least git / bzr users don't get confused. > > > > How often is anything added to the .hgignore file? I doubt that these > files > > will "sufficiently always" be outdated to be unhelpful. > > How about using symlinks and only using a common syntax in .hgignore > that git also understands? > Because .hgignore has a more expressive syntax. We shouldn't hobble or make messy our hg repo just for the sake of git. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418: rename time.monotonic() to time.steady()?
On Tue, Apr 3, 2012 at 23:14, Victor Stinner wrote: >> Wait, what? >> I already thought we, several days ago, decided that "steady" was a >> *terrible* name, and that monotonic should *not* fall back to the >> system clock. > > Copy of a more recent Guido's email: > http://mail.python.org/pipermail/python-dev/2012-March/118322.html > "Anyway, 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. So forget the idea about one version > that falls back to time.time() and another that doesn't -- just always > fall back to time.time(), which is (almost) always better than > failing. I disagree with this, mainly for the reason that there isn't any good names for these functions. "hopefully_monotonic()" doesn't really cut it for me. :-) I also don't see how it's hard to guarantee that monotonic() is monotonic. //Lennart ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418: rename time.monotonic() to time.steady()?
On Wed, 4 Apr 2012 17:30:26 +0200 Lennart Regebro wrote: > > Copy of a more recent Guido's email: > > http://mail.python.org/pipermail/python-dev/2012-March/118322.html > > "Anyway, 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. So forget the idea about one version > > that falls back to time.time() and another that doesn't -- just always > > fall back to time.time(), which is (almost) always better than > > failing. > > I disagree with this, mainly for the reason that there isn't any good > names for these functions. "hopefully_monotonic()" doesn't really cut > it for me. :-) monotonic(fallback=False) doesn't look horrible to me (assuming a default value of False for the `fallback` parameter). > I also don't see how it's hard to guarantee that monotonic() is monotonic. I think we are speaking about a system-wide monotonic clock (i.e., you can compare values between processes). Otherwise it's probably quite easy indeed. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
I am fine with the PEP as it is now (2012-04-04 15:34 GMT). A question: Since the only monotonic clock that can be adjusted by NTP is Linux' CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always give a clock that isn't adjusted by NTP. That would however mean we wouldn't support monotonic clocks on systems that run a Linux that is older than mid-2008. Is this generally seen as a problem? //Lennart ___ Python-Dev mailing list [email protected] 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 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 [email protected] 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 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
On 2012-04-03, at 9:28 PM, Victor Stinner wrote: > In the last version of my PEP, time.monotonic() is simply defined as "a > monotonic clock (cannot go backward)". There is no more "... best ..." in its > definition. I like the last version of the PEP ;) - Yury ___ Python-Dev mailing list [email protected] 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 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
[email protected]
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 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/[email protected]
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
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 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
[email protected]
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 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
[email protected]
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 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
[email protected]
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/[email protected]
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
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
[email protected]
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 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 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 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
[email protected]
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
[email protected]
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/[email protected]
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
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 : > On Wed, Apr 4, 2012 at 13:04, Victor Stinner wrote: >> It depends if the option supports other values. But as I understood, >> the keyword value must always be True. > > Or False, obviously. Which would also be default. Ok for the default, but what happens if the caller sets an option to False? Does get_clock(monotonic=False) return a non-monotonic clock? (I guess no, but it may be confusing.) Victor ___ Python-Dev mailing list [email protected] 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 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 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
> I failed to propose a consistent and clear API because I (and Guido!) wanted
> to fallback to the system clock. Falling back to the system clock is a
> problem when you have to define the function in the documentation or if you
> don't want to use the system clock (but do something else) if no monotonic
> clock is available.
More details why it's hard to define such function and why I dropped
it from the PEP.
If someone wants to propose again such function ("monotonic or
fallback to system" clock), two issues should be solved:
- name of the function
- description of the function
At least, "monotonic" and "steady" names are not acceptable names for
such function, even if the function has an optional "strict=False" or
"fallback=True" parameter. By the way, someone complained that having
a boolean parameter requires to create a new function if you want to
call it without an argument (use a lambda function, functools.partial,
or anything else). Example:
get_time = lambda: try_monotonic(fallback=True)
t = get_time()
The description should give the least guarantees.
If the function doesn't promise anything (or only a few weak
properties), it is harder to decide which clock do you need for your
use case: time.clock(), time.time(), time.monotonic(), time., ...
Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Failed issue tracker submission
An unexpected error occurred during the processing of your message. The tracker administrator is being notified. Return-Path: X-Original-To: [email protected] Delivered-To: [email protected] Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id 18F1D1CA8A for ; Thu, 5 Apr 2012 03:29:47 +0200 (CEST) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3VNRKk5ffZzMDH for ; Thu, 5 Apr 2012 03:29:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1333589386; bh=mxZYtp1PNBk7+3KkQ2c0Ir4UpBYOh1g7JxosMonW0bg=; h=Date:Message-Id:Content-Type:MIME-Version: Content-Transfer-Encoding:From:To:Subject; b=dkAMMMzcIiS6RnMbU2X82n0soHqci8LQJeJZtQefi9I0bhSh9IbG/qrBrdjTdG3sE QOAeN4ttDr5vy83SY7pcXGH4sXVAlMGHAwKPUcOYRFIHKzKoy/gNwOfPRRIdxDg3C0 Go6dQtIJi0j/uS4EI9o7oEJHVczuzJLkdGRcA6ik= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 05 Apr 2012 03:29:46 +0200 Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for ; Thu, 5 Apr 2012 03:29:46 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=dinsdale.python.org ident=hg) by dinsdale.python.org with esmtp (Exim 4.72) (envelope-from ) id 1SFbWE-0008LO-KB for [email protected]; Thu, 05 Apr 2012 03:29:46 +0200 Date: Thu, 05 Apr 2012 03:29:46 +0200 Message-Id: Content-Type: text/plain; charset="utf8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: [email protected] To: [email protected] Subject: [issue14490] TmV3IGNoYW5nZXNldCA2MmRkZTVkZDQ3NWUgYnkgUiBEYXZpZCBNdXJyYXkgaW4gYnJhbmNoICcz LjInOgojMTQ0OTAsICMxNDQ5MTogYWRkICdzdW5kcnknLXN0eWxlIGltcG9ydCB0ZXN0cyBmb3Ig VG9vbHMvc2NyaXB0cy4KaHR0cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvNjJkZGU1ZGQ0 NzVlCgoKTmV3IGNoYW5nZXNldCA2OTZjYjUyNDMyMmEgYnkgUiBEYXZpZCBNdXJyYXkgaW4gYnJh bmNoICdkZWZhdWx0JzoKTWVyZ2UgIzE0NDkwLCAjMTQ0OTE6IGFkZCAnc3VuZHJ5Jy1zdHlsZSBp bXBvcnQgdGVzdHMgZm9yIFRvb2xzL3NjcmlwdHMuCmh0dHA6Ly9oZy5weXRob24ub3JnL2NweXRo b24vcmV2LzY5NmNiNTI0MzIyYQo= ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
Lennart Regebro wrote: Since the only monotonic clock that can be adjusted by NTP is Linux' CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always give a clock that isn't adjusted by NTP. I thought we decided that NTP adjustment isn't an issue, because it's always gradual. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failed issue tracker submission
On Thu, 05 Apr 2012 01:29:47 -, Python tracker wrote: > > An unexpected error occurred during the processing > of your message. The tracker administrator is being > notified. Since the bounce message went here, I'm posting this here for those who are curious what caused it. It was triggered by my committing a patch with two issue numbers in the commit message. This triggered a DB lock problem on the roundup end, from the xapian indexer: Traceback (most recent call last): File "/home/roundup/lib/python2.5/site-packages/roundup/mailgw.py", line 1395, in handle_Message return self.handle_message(message) File "/home/roundup/lib/python2.5/site-packages/roundup/mailgw.py", line 1451, in handle_message return self._handle_message(message) File "/home/roundup/lib/python2.5/site-packages/roundup/mailgw.py", line 1529, in _handle_message parsed_message.create_msg() File "/home/roundup/lib/python2.5/site-packages/roundup/mailgw.py", line 1105, in create_msg messageid=messageid, inreplyto=inreplyto, **self.msg_props) File "/home/roundup/lib/python2.5/site- packages/roundup/backends/rdbms_common.py", line 2958, in create content, mime_type) File "/home/roundup/lib/python2.5/site- packages/roundup/backends/indexer_xapian.py", line 59, in add_text database = self._get_database() File "/home/roundup/lib/python2.5/site- packages/roundup/backends/indexer_xapian.py", line 21, in _get_database return xapian.WritableDatabase(index, xapian.DB_CREATE_OR_OPEN) File "/usr/lib/python2.6/dist-packages/xapian/__init__.py", line 4059, in __init__ _xapian.WritableDatabase_swiginit(self,_xapian.new_WritableDatabase(*args)) DatabaseLockError: Unable to get write lock on /home/roundup/trackers/tracker/db /text-index: already locked The Xapian index is new since the server upgrade, so it is possible this will always happen when more than one issue number is mentioned. Or it could be a random timing thing. Presumably it could also occur during normal web submissions if they happen to happen at the same time, which is a little bit worrisome. If anyone has any Xapien experience and would be willing to help out with debugging this and/or some indexing issues, please let me know :) --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
On Apr 4, 2012 7:28 PM, "Victor Stinner" wrote:
>
> More details why it's hard to define such function and why I dropped
> it from the PEP.
>
> If someone wants to propose again such function ("monotonic or
> fallback to system" clock), two issues should be solved:
>
> - name of the function
> - description of the function
Maybe I missed it, but did anyone ever give a reason why the fallback
couldn't be to Steven D'Aprano's monotonic wrapper algorithm over the
system clock? (Given a suitable minimum delta.) That function appeared to
me to provide a sufficiently monotonic clock for timeout purposes, if
nothing else.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
On 04Apr2012 22:23, PJ Eby wrote:
| On Apr 4, 2012 7:28 PM, "Victor Stinner" wrote:
| > More details why it's hard to define such function and why I dropped
| > it from the PEP.
| >
| > If someone wants to propose again such function ("monotonic or
| > fallback to system" clock), two issues should be solved:
| >
| > - name of the function
| > - description of the function
|
| Maybe I missed it, but did anyone ever give a reason why the fallback
| couldn't be to Steven D'Aprano's monotonic wrapper algorithm over the
| system clock? (Given a suitable minimum delta.) That function appeared to
| me to provide a sufficiently monotonic clock for timeout purposes, if
| nothing else.
It was pointed out (by Nick Coglan I think?) that if the system clock
stepped backwards then a timeout would be extended by at least that
long. For example, code that waited (by polling the synthetic clock)
for 1s could easily wait an hour if the system clock stepped back that
far. Probaby undesirable.
I think synthetic clocks are an extra task; they will all have side
effects of one kind of another.
A system monotonic clock, by contrast, may have access to some clock
hardware that doesn't step when the "main" system clock gets adjusted,
and can stay monotonic. A synthetic clock without such access can't
behave as nicely.
If synthetic clocks get handed out as fallback there should be some way
for the user to know, or a big glaring negative guarrentee in the docs
and on platforms without a system monotonic clock you might get a clock
with weird (but monotonic!) behaviours if you use the fallback.
Cheers,
--
Cameron Simpson DoD#743
http://www.cskk.ezoshosting.com/cs/
Tachyon: A gluon that's not completely dry.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
On Thu, Apr 5, 2012 at 1:41 PM, Cameron Simpson wrote: > It was pointed out (by Nick Coglan I think?) that if the system clock > stepped backwards then a timeout would be extended by at least that > long. Guido pointed it out (it was in a reply to me, though). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
