Cameron Simpson wrote:
I maintain that
"monotonic" still means what I said, and that it is the combination of
the word with "clock" that brings in your other criteria.
I'm not trying to redefine the word "monotonic" in general.
All I'm saying is that *if* the PEP is going to talk about
a "mono
Steven D'Aprano wrote:
Greg Ewing wrote:
the important thing about a clock that it *keeps going forward*
That would be a *strictly* monotonic clock, as opposed to merely monotonic.
Well, yes, but even that's not enough -- it needs to go forward
at a reasonably constant rate, otherwise it's
On Fri, Apr 6, 2012 at 3:39 PM, Glyph Lefkowitz wrote:
> There seems to be a persistent desire in this discussion to specify and
> define these flaws out of existence, where this API really should instead be
> embracing the flaws and classifying them.
That seems to be precisely what Cameron is a
Glyph Lefkowitz wrote:
On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote:
2. Those who think that "monotonic clock" means a clock that never jumps,
and that runs at a rate approximating the rate of real time. This is a
very useful kind of clock to have! It is what C++ now calls a "steady
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 6 April 2012 02:50, Cameron Simpson wrote:
(Quoted from the Linux manpage)
> All implementations support the system-wide real-time clock, which
> is identified by CLOCK_REALTIME. Its time represents seconds and
> nanoseconds since the Epoch. When its time is changed, timers for
> a
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
On 6 April 2012 11:12, Steven D'Aprano wrote:
> Glyph Lefkowitz wrote:
>
>> On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote:
>>
>
> 2. Those who think that "monotonic clock" means a clock that never jumps,
>>> and that runs at a rate approximating the rate of real time. This is a
>>> very
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
I just had my first fun with Pep 393 strings and debuggers. Trying to debug a
deadlocked python program, I'm trying to figure out the callstack of the thread
in the debugger.
I ended up with something like:
(char*)&((PyASCIIObject*)(tstate->frame->f_code->co_filename))[1]
while previously
2012/4/6 Kristján Valur Jónsson :
> I wonder if there is a way to make this situation easier? Perhaps for
> "debug" builds, we can store some debug information in the frame object,
> e.g. utf8 encoding of the filename and function?
Have you tried using the cpython gdb plugin? It should repr these
> 2. Those who think that "monotonic clock" means a clock that never
> jumps, and that runs at a rate approximating the rate of real time.
> This is a very useful kind of clock to have! It is what C++ now calls
> a "steady clock". It is what all the major operating systems provide.
Python cannot g
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
I'd like to veto wall clock because to me that's the clock on my wall, i.e.
local time. Otherwise I like the way this thread is going.
--Guido van Rossum (sent from Android phone)
On Apr 6, 2012 4:57 AM, "Paul Moore" wrote:
> On 6 April 2012 11:12, Steven D'Aprano wrote:
>
>> Glyph Lefkowitz wr
ACTIVITY SUMMARY (2012-03-30 - 2012-04-06)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3360 ( +1)
closed 22935 (+64)
total 26295 (+65)
Open issues wit
This is the most amusing of discussions.
Teh key sentence here is "the clock may not be adjusted". Slewing or
accelerating a clock is nerely adding to the already present error of the pace
of the clock.
Sometimes a clock runs fast, sometimes it runs slow. This is without any
purposeful slewing
This is the original reason for the original defect (issue 10278)
unix' clock() doesn't actually provide a clock in this sense, it provides a
resource usage metric.
K
Frá: python-dev-bounces+kristjan=ccpgames@python.org
[python-dev-bounces+kristjan=cc
There is a problem with the way logging.handlers.SysLogHandler works
when presented with Unicode messages. According to RFC 5424, Unicode
is supposed to be sent encoded as UTF-8 and preceded by a BOM.
However, the current handler implementation puts the BOM at the start
of the formatted message, an
On Thu, Apr 5, 2012 at 12:32, Victor Stinner wrote:
> I prefer to use CLOCK_MONOTONIC, not because it is also available for
> older Linux kernels, but because it is more reliable. Even if the
> underlying clock source is unstable (unstable frequency), a delta of
> two reads of the CLOCK_MONOTONIC
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
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
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
On 06Apr2012 15:19, I wrote:
| On 06Apr2012 14:31, Steven D'Aprano wrote:
| | Here is a non-monotonic sequence:
| |
| | 1, 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7, 8
| |
| | This isn't steady either, because it jumps backwards.
| |
| | To be steady, it MUST also be monotonic. If you think that it is
On 4 April 2012 10:33, Steven D'Aprano wrote:
> try:
>from os import bestclock as _bestclock
> except ImportError:
>_bestclock = time
>
My problem here is that "best clock" means different things to different
people (as the number of emails shows).
I think exposing specific clocks is al
On 06Apr2012 17:07, Kristj�n Valur J�nsson wrote:
| Steven D'Aprano:
| > I think that this is incorrect.
| > py> time.clock(); time.sleep(10); time.clock()
| > 0.41
| > 0.41
|
| This is the original reason for the original defect (issue 10278)
| unix' clock() doesn't actually provide a clock in th
> 1. The "steadiest" clock on the system. Ideally this would be a steady
> clock, but may not be.
time.monotonic() as proposed in the PEP 418 *is* the steadiest
available clock, but we cannot say that it is steady :-)
> 2. The "most precise" clock on the system. This would have the finest-grain
>
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
> | This is the original reason for the original defect (issue 10278)
> | unix' clock() doesn't actually provide a clock in this sense, it provides a
> resource usage metric.
>
> Yeah:-( Its help says "Return the CPU time or real time since [...]".
> Two very different things, as demonstrated. I s
> 2. Those who think that "monotonic clock" means a clock that never
> jumps, and that runs at a rate approximating the rate of real time.
> This is a very useful kind of clock to have! It is what C++ now calls
> a "steady clock". It is what all the major operating systems provide.
For the "C++" p
On 4/5/2012 6:32 AM, Victor Stinner 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 alwa
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 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,
32 matches
Mail list logo
