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 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
> -Original Message-
> From: gvanros...@gmail.com [mailto:gvanros...@gmail.com] On Behalf
> Of Guido van Rossum
> Sent: 2. apríl 2012 17:43
> To: Kristján Valur Jónsson
> Cc: Cameron Simpson; Python Dev
> Subject: Re: [Python-Dev] Use QueryPerformanceCounter() for
> time.monotonic() and/o
Hi,
I would to rename time.monotonic() to time.steady() in the PEP 418 for
the following reasons:
- time.steady() may fallback to the system clock which is not
monotonic, it's strange to have to check for
time.get_clock_info('monotonic')['is_monotonic']
- time.steady() uses GetTickCount() inste
>> You seem to have missed the episode where I explained that caching the last
>> value in order to avoid going backwards doesn't work -- at least not if the
>> cached value is internal to the API implementation.
>>
> Yes, and I can't find it by briefly searching my mail. I haven't had the
> ener
Victor Stinner wrote:
>>> You seem to have missed the episode where I explained that caching the last
>>> value in order to avoid going backwards doesn't work -- at least not if the
>>> cached value is internal to the API implementation.
>>>
>> Yes, and I can't find it by briefly searching my mail.
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 Tue, Apr 3, 2012 at 13:26, Victor Stinner wrote:
> Hi,
>
> I would to rename time.monotonic() to time.steady() in the PEP 418 for
> the following reasons:
>
> - time.steady() may fallback to the system clock which is not
> monotonic, it's strange to have to check for
> time.get_clock_info('mon
> -Original Message-
> From: python-dev-bounces+kristjan=ccpgames@python.org
> [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On
> Behalf Of Lennart Regebro
> Sent: 3. apríl 2012 14:14
> To: Victor Stinner
> Cc: Python Dev
> Subject: Re: [Python-Dev] PEP 418: rename time
The discussion has completed degenerated. There are several different
clocks here, and several different agendas.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mai
On Tue, 03 Apr 2012 22:42:37 +0800, Matt Joiner wrote:
> The discussion has completed degenerated. There are several different
> clocks here, and several different agendas.
It's probably time to do a reset. Read Victor's PEP, and help
him edit it so that it accurately reflects the various argume
> -Original Message-
> From: python-dev-bounces+kristjan=ccpgames@python.org
> Some years? I computed 584.5 years, so it should not occur in practice.
Funny that you mention it. "should not occur in practice" is exactly my point.
> > Here's actual code from production:
> >
> > BOOL
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 Apr 03, 2012, at 12:44 AM, Antoine Pitrou wrote:
>I don't think Barry still uses bzr, and who ever used git to manage their
>patches against the CPython repo?
I still use bzr, but not currently for Python development. I just use the
standard hg repo. I'd like to go back to it though once the
I filed the issue http://bugs.python.org/issue14470 for removing
w9xopen from subprocess as python 3.3 has declaration about finishing
support of Windows 2000 and Win9x family.
But, as I see, VC project for building w9xopen is still present.
Should we remove it as well?
--
Thanks,
Andrew Svetlov
On Tue, Apr 3, 2012 at 14:59, Andrew Svetlov wrote:
> I filed the issue http://bugs.python.org/issue14470 for removing
> w9xopen from subprocess as python 3.3 has declaration about finishing
> support of Windows 2000 and Win9x family.
> But, as I see, VC project for building w9xopen is still prese
Done. Thanks.
On Tue, Apr 3, 2012 at 11:08 PM, Brian Curtin wrote:
> On Tue, Apr 3, 2012 at 14:59, Andrew Svetlov wrote:
>> I filed the issue http://bugs.python.org/issue14470 for removing
>> w9xopen from subprocess as python 3.3 has declaration about finishing
>> support of Windows 2000 and Win
> 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
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?
| >
On Sat, Mar 31, 2012 at 7:45 PM, R. David Murray wrote:
> On Sun, 01 Apr 2012 03:03:13 +1000, Nick Coghlan
> wrote:
> > On Sun, Apr 1, 2012 at 2:09 AM, Guido van Rossum
> wrote:
> > > Here's a different puzzle. Has anyone written a demo yet that provokes
> > > this RuntimeError, without cheating
On 03Apr2012 13:26, Victor Stinner wrote:
| I would to rename time.monotonic() to time.steady() in the PEP 418 for
| the following reasons:
|
| - time.steady() may fallback to the system clock which is not
| monotonic, it's strange to have to check for
| time.get_clock_info('monotonic')['is_mono
I'm confused. Are you saying that that program always raised
RuntimeError, or that it started raising RuntimeError with the new
behavior (3.3 alpha 2)?
On Tue, Apr 3, 2012 at 2:47 PM, Maciej Fijalkowski wrote:
> On Sat, Mar 31, 2012 at 7:45 PM, R. David Murray
> wrote:
>>
>> On Sun, 01 Apr 2012
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
Never mind, I got it. This always raised RuntimeError. I see this
should be considered support in favor of keeping the change, since
sharing dicts between threads without locking is already fraught with
RuntimeErrors.
At the same time, has anyone looked at my small patch (added to the
issue) that
Cameron Simpson wrote:
Sigh. They're different things! For all that "steady" is a slightly
vague term, steady and hires and monotonic are independent concepts. Of
course a lot of high quality clocks will embody hires and ideally steady
or monotonic.
This kind of offer-just-one-thing embedded pol
Hello,
I worked on a patch to support half-floats about a year ago, and the
impression I got from the python-dev list was that there wasn't anyone
with objections to the patch, and from the reviewers was that it was
ready for inclusion, but it never moved beyond that stage (I should
have pushed it
[ Returning at more leisure... ]
On 04Apr2012 07:53, I wrote:
| On 03Apr2012 13:26, Victor Stinner wrote:
| | I would to rename time.monotonic() to time.steady() in the PEP 418 for
| | the following reasons:
| | - time.steady() may fallback to the system clock which is not
| | monotonic, it's st
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
> | 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 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
Hi,
We are organizing a micro-conference on scaling both upwards (many
cores) and downwards (low footprint, energy efficiency) that targets
all layers of the software stack. Our intent is to bring together
application, libraries and kernel developers to discuss the scalability
issues they currentl
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 causi
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
> 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
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
On 04/04/2012 00:31, Cameron Simpson wrote:
[ Returning at more leisure... ]
I think Kristj\341n Valur J\363nsson is on point when he says "There is
no such thing as steady time", but the notion is very attractive. If
you're going to return a "steady" clock you should be able to find out
how stea
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
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.
Everyone has a different opinion, everyone belie
On Wed, Apr 4, 2012 at 10:33 AM, Steven D'Aprano wrote:
> Python has worked pretty well without high res and monotonic clocks for 20
> years. Let's not rush into a suboptimal design based on who can outlast
> everyone else in this discussion.
+1
FWIW, I'd be fine with underscore prefixes on *any
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?
| >
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
On 2012-04-03, at 8:33 PM, Steven D'Aprano wrote:
> 1) the os module should expose lightweight wrappers around whatever clocks
> the operating system provides;
+1. That should make it flexible enough to those who really need it.
> 2) the time module should NOT provide any further clocks other
Finally! We've come full circle.
+1 for monotonic as just described by 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%40
Lock it in before the paint dries.
On Apr 4, 2012 10:05 AM, "Matt Joiner" wrote:
> Finally! We've come full circle.
>
> +1 for monotonic as just described by Victor.
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
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_
45 matches
Mail list logo
