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_
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
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
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
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 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 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
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 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
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
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 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
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 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
[ 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
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
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
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:
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
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
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
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 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?
| >
> 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
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
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
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 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
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
> -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
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
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
> -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
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
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
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.
>> 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
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
> -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
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
45 matches
Mail list logo
