On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote:
> On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing
> wrote:
>>
>> This is the strict mathematical meaning of the word "monotonic", but the way
>> it's used in relation to OS clocks, it seems to mean rather more than that.
>
> Yep. As far as I
On 06Apr2012 14:31, Steven D'Aprano wrote:
| Cameron Simpson wrote:
| > | The main reason to use the word "monotonic clock" to refer to the
| > | second concept is that POSIX does so, but since Mac OS X, Solaris,
| > | Windows, and C++ have all avoided following POSIX's mistake, I think
| > | Pyth
Cameron Simpson wrote:
| The main reason to use the word "monotonic clock" to refer to the
| second concept is that POSIX does so, but since Mac OS X, Solaris,
| Windows, and C++ have all avoided following POSIX's mistake, I think
| Python should too.
No. If it is not monotonic, DO NOT CALL IT
On 05Apr2012 21:07, Zooko Wilcox-O'Hearn wrote:
| On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing
wrote:
| > This is the strict mathematical meaning of the word "monotonic",
| > but the way it's used in relation to OS clocks, it seems to mean rather
| > more than that.
|
| Yep. As far as I can tell,
On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing wrote:
>
> This is the strict mathematical meaning of the word "monotonic", but the way
> it's used in relation to OS clocks, it seems to mean rather more than that.
Yep. As far as I can tell, nobody has a use for an unsteady, monotonic clock.
There se
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
Greg Ewing wrote:
Cameron Simpson wrote:
A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent
polls of the clock. On its own it says nothing about steadiness or
correlation with real world time.
No, no, no.
This is the strict mathematical meaning of the word "monotonic",
but
On 06Apr2012 13:14, Greg Ewing wrote:
| Cameron Simpson wrote:
| > A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent
| > polls of the clock. On its own it says nothing about steadiness or
| > correlation with real world time.
|
| No, no, no.
| This is the strict mathematical me
Cameron Simpson wrote:
A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent
polls of the clock. On its own it says nothing about steadiness or
correlation with real world time.
No, no, no.
This is the strict mathematical meaning of the word "monotonic",
but the way it's used
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 Apr 5, 2012 11:01 AM, "Guido van Rossum" wrote:
> I think it would be better if the proposed algorithm (or whatever
> algorithm to "fix" timeouts) was implemented by the
> application/library code using the timeout (or provided as a separate
> library function), rather than by the clock, since
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 (
On 05Apr2012 13:39, Zooko Wilcox-O'Hearn wrote:
| Good job, Victor Stinner on baking the accumulated knowledge of this
| thread into PEP 418. Even though I'm very interested in the topic, I
| haven't been able to digest the whole thread(s) on the list and
| understand what the current collective u
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 09:56, Guido van Rossum wrote:
| On Thu, Apr 5, 2012 at 9:48 AM, PJ Eby wrote:
| > What's missing is that if you're using a monotonic clock for timeouts, then
| > a monotonically-adjusted system clock can do that, subject to the polling
| > frequency -- it does not break just because
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 5, 2012 at 8:19 PM, Terry Reedy wrote:
>
> I have been hoping to work on a proper tkinter doc. I discovered some time
> ago through the pydoc server (not currently working for me, see
> http://bugs.python.org/issue14512)
> that their are doc strings for (most) everything. I have been m
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,
Folks:
Good job, Victor Stinner on baking the accumulated knowledge of this
thread into PEP 418. Even though I'm very interested in the topic, I
haven't been able to digest the whole thread(s) on the list and
understand what the current collective understanding is. The detailed
PEP document helps
On Thu, Apr 5, 2012 at 12:56 PM, Guido van Rossum wrote:
> Depending on the polling frequency sounds like a bad idea, since you
> can't know that you're the only user of the clock. Also depending on
> the use case, too short a timeout may be worse than too long a
> timeout.
Given a small enough
Victor Stinner wrote:
I changed time.monotonic() to not fallback to the system clock exactly
for this reason: Python cannot guess what the developer expects, or
how the developer will use the clock.
Which is exactly why I like Cameron Simpson's approach to selecting a
clock -- let the develope
>> > For timeout purposes in a single process, such a clock is useful. It just
>> > isn't suitable for benchmarks, or for interprocess coordination.
>>
>> I think it would be better if the proposed algorithm (or whatever
>> algorithm to "fix" timeouts) was implemented by the
>> application/library
On 4/5/2012 10:06 AM, R. David Murray wrote:
(reformatted to remove topposting)
On Thu, 05 Apr 2012 14:52:56 +0300, Andrew Svetlov
wrote:
On Thu, Apr 5, 2012 at 1:21 PM, Antoine Pitrou wrote:
Aren't there any docs?
Maybe you will be surprised, but tkinter.rst has no comprehensive docs
f
On Thu, 5 Apr 2012 09:56:19 -0700
Guido van Rossum wrote:
>
> > For timeout purposes in a single process, such a clock is useful. It just
> > isn't suitable for benchmarks, or for interprocess coordination.
>
> I think it would be better if the proposed algorithm (or whatever
> algorithm to "fi
On Thu, Apr 5, 2012 at 9:48 AM, PJ Eby wrote:
>
>
> On Thu, Apr 5, 2012 at 6:34 AM, Victor Stinner
> wrote:
>>
>> 2012/4/5 PJ Eby :
>> >> 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 ("monot
On Thu, Apr 5, 2012 at 6:34 AM, Victor Stinner wrote:
> 2012/4/5 PJ Eby :
> >> 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 s
On Wed, Apr 4, 2012 at 11:41 PM, Cameron Simpson wrote:
> 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
On Thu, 05 Apr 2012 08:32:22 -0700
Ethan Furman wrote:
>
> Steven D'Aprano's synthetic clock is able to partially avoid that
> situation -- worst case is a timeout of double what you asked for -- so
> 10 seconds instead of 5 (which is much better than 3600!).
The remaining issue is that the cl
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'
Cameron Simpson wrote:
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"
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, 05 Apr 2012 17:34:07 +0300, Andrew Svetlov
wrote:
> Thank you, David.
> Is separate repo clone located at hg.python.org good enough? Or maybe
> there are better way to do it?
That sounds like a good plan to me.
--David
___
Python-Dev mailing l
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
Thank you, David.
Is separate repo clone located at hg.python.org good enough? Or maybe
there are better way to do it?
On Thu, Apr 5, 2012 at 5:06 PM, R. David Murray wrote:
> (reformatted to remove topposting)
>
> On Thu, 05 Apr 2012 14:52:56 +0300, Andrew Svetlov
> wrote:
>> On Thu, Apr 5, 20
(reformatted to remove topposting)
On Thu, 05 Apr 2012 14:52:56 +0300, Andrew Svetlov
wrote:
> On Thu, Apr 5, 2012 at 1:21 PM, Antoine Pitrou wrote:
> > On Thu, 05 Apr 2012 11:41:48 +0200
> > andrew.svetlov wrote:
> >> http://hg.python.org/cpython/rev/774c2afa6665
> >> changeset: Â 76115:774c
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
Hi there. Antoine Pitrou suggested that I float this on python-dev again. The
new patch should
1) be much simpler and less hacky
2) remove the special case code for PyGenObject from gcmodule.c
K
Frá: Kristján Valur Jónsson [rep...@bugs.python.org]
Sent: 5
Maybe you will be surprised, but tkinter.rst has no comprehensive docs
for any tkinter class.
I like to get it fixed but definitely cannot do it myself. My very
poor English is the main objection for writing narrative
documentation.
On Thu, Apr 5, 2012 at 1:21 PM, Antoine Pitrou wrote:
> On Thu,
2012/4/5 PJ Eby :
>> 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 funct
>>> Since the only monotonic clock that can be adjusted by NTP is Linux'
>>> CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
>>> give a clock that isn't adjusted by NTP.
>>
>> I thought we decided that NTP adjustment isn't an issue, because
>> it's always gradual.
>
> Well, in t
On Thu, 05 Apr 2012 11:41:48 +0200
andrew.svetlov wrote:
> http://hg.python.org/cpython/rev/774c2afa6665
> changeset: 76115:774c2afa6665
> user:Andrew Svetlov
> date:Thu Apr 05 12:41:20 2012 +0300
> summary:
> Issue #3033: Add displayof parameter to tkinter font.
> Patch by Gu
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 Thu, Apr 5, 2012 at 00:45, Greg Ewing wrote:
> Lennart Regebro wrote:
>>
>> Since the only monotonic clock that can be adjusted by NTP is Linux'
>> CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
>> give a clock that isn't adjusted by NTP.
>
> I thought we decided that NTP a
50 matches
Mail list logo
