On 04/28/2012 04:20 PM, Eric V. Smith wrote:
But we generally use a namedtuple (or structseq) for things like
get_clock_info. For example, for sys.float_info there's no need for it
to be a tuple, and it can be extended in the future, yet it's a structseq.
I'd prefer an object to a dict, but
On 4/29/2012 4:41 AM, Larry Hastings wrote:
On 04/28/2012 04:20 PM, Eric V. Smith wrote:
But we generally use a namedtuple (or structseq) for things like
get_clock_info. For example, for sys.float_info there's no need for it
to be a tuple, and it can be extended in the future, yet it's a
On 04/29/2012 02:01 AM, Eric V. Smith wrote:
On 4/29/2012 4:41 AM, Larry Hastings wrote:
I'd prefer an object to a dict, but not a tuple / structseq. There's no
need for the members to be iterable.
I agree with you, but there's already plenty of precedent for this.
[...] Iteration for these
On Sun, 29 Apr 2012 02:12:41 -0700
Larry Hastings la...@hastings.org wrote:
On 04/29/2012 02:01 AM, Eric V. Smith wrote:
On 4/29/2012 4:41 AM, Larry Hastings wrote:
I'd prefer an object to a dict, but not a tuple / structseq. There's no
need for the members to be iterable.
I agree with
On Sun, 29 Apr 2012 03:26:26 +0200
Victor Stinner victor.stin...@gmail.com wrote:
Hi Guido,
2012/4/28 Guido van Rossum gu...@python.org:
I read most of the PEP and I think it is ready for acceptance! Thanks
for your patience in shepherding this through such a difficult and
long
On Sun, Apr 29, 2012 at 5:29 AM, Steven D'Aprano st...@pearwood.info wrote:
Larry Hastings wrote:
On 04/29/2012 02:01 AM, Eric V. Smith wrote:
On 4/29/2012 4:41 AM, Larry Hastings wrote:
I'd prefer an object to a dict, but not a tuple / structseq. There's no
need for the members to be
On Sat, Apr 28, 2012 at 6:26 PM, Victor Stinner
victor.stin...@gmail.com wrote:
Hi Guido,
2012/4/28 Guido van Rossum gu...@python.org:
I read most of the PEP and I think it is ready for acceptance! Thanks
for your patience in shepherding this through such a difficult and
long discussion.
On Sat, Apr 28, 2012 at 1:32 PM, Victor Stinner
victor.stin...@gmail.com wrote:
As a thin wrapper, adding it to the time module was pretty much
uncontroversial, I think. The PEP proposes cross-platform
functions with consistent semantics, which is where a discussion was
needed.
True, but
Surely those are all very minor quibbles. I have one myself: at some
point it says:
On Linux, it is possible to use
time.clock_gettime(CLOCK_THREAD_CPUTIME_ID).
But the PEP doesn't define a function by that name. Is it an editing
glitch? (Some of the pseudo code also uses this.)
It is
3) The dict returned by get_clock_info includes an optional key,
is_adjusted. Why is it optional?
More complete answer.
Rules used to fill the is_adjusted flag:
- System clock: is_adjusted=1 because the clock can be set manually
by the system administrator, except on Windows: is_adjusted is
On Sat, Apr 28, 2012 at 12:40 AM, Victor Stinner
victor.stin...@gmail.com wrote:
Surely those are all very minor quibbles. I have one myself: at some
point it says:
On Linux, it is possible to use
time.clock_gettime(CLOCK_THREAD_CPUTIME_ID).
But the PEP doesn't define a function by that
On Sat, 28 Apr 2012 07:02:13 -0700
Guido van Rossum gu...@python.org wrote:
It is this function:
http://docs.python.org/dev/library/time.html#time.clock_gettime
It's just a binding of the C function clock_gettime(). Should the PEP
describe all functions used by the PEP?
Oh, now I'm
On Sat, Apr 28, 2012 at 7:51 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 28 Apr 2012 07:02:13 -0700
Guido van Rossum gu...@python.org wrote:
It is this function:
http://docs.python.org/dev/library/time.html#time.clock_gettime
It's just a binding of the C function
As a thin wrapper, adding it to the time module was pretty much
uncontroversial, I think. The PEP proposes cross-platform
functions with consistent semantics, which is where a discussion was
needed.
True, but does this mean clock_gettime and friends only exist on
POSIX? Shouldn't they be in
On 4/27/2012 11:40 PM, Guido van Rossum wrote:
On Fri, Apr 27, 2012 at 5:50 PM, Steven D'Aprano st...@pearwood.info wrote:
2) get_clock_info returns a dict. Why not a namedtuple?
Future flexibility. And there's no need for it to be a *tuple*.
I haven't been paying attention to this
2) get_clock_info returns a dict. Why not a namedtuple?
Future flexibility. And there's no need for it to be a *tuple*.
I haven't been paying attention to this discussion, so this isn't a
comment on any time functions specifically.
But we generally use a namedtuple (or structseq) for
Hi Guido,
2012/4/28 Guido van Rossum gu...@python.org:
I read most of the PEP and I think it is ready for acceptance! Thanks
for your patience in shepherding this through such a difficult and
long discussion.
You're welcome, but many developers helped me!
Also thanks to the many other
Hi Victor,
I read most of the PEP and I think it is ready for acceptance! Thanks
for your patience in shepherding this through such a difficult and
long discussion. Also thanks to the many other contributors,
especially those who ended up as co-authors. We will have an awesome
new set of time
Some issues with the PEP 418:
1) time.clock is deprecated, but also supported by get_clock_info. Why bother
supporting it if you don't want people to use it?
2) get_clock_info returns a dict. Why not a namedtuple?
3) The dict returned by get_clock_info includes an optional key,
1) time.clock is deprecated, but also supported by get_clock_info. Why
bother supporting it if you don't want people to use it?
It will not be removed before Python 4, the function is still used by
Python 3.3.
2) get_clock_info returns a dict. Why not a namedtuple?
I don't like the tuple
On Fri, Apr 27, 2012 at 5:50 PM, Steven D'Aprano st...@pearwood.info wrote:
Some issues with the PEP 418:
1) time.clock is deprecated, but also supported by get_clock_info. Why
bother supporting it if you don't want people to use it?
I see the deprecation of clock() as mostly symbolic --
Here is a simplified version of the first draft of the PEP 418. The
full version can be read online.
http://www.python.org/dev/peps/pep-0418/
Thanks to everyone who helped me to work on this PEP!
I integrated last comments. There is no more open question. (Or did I
miss something?)
I didn't
2012/4/15 Victor Stinner victor.stin...@gmail.com:
Here is a simplified version of the first draft of the PEP 418. The
full version can be read online.
http://www.python.org/dev/peps/pep-0418/
FYI there is no time.thread_time() function. It would only be
available on Windows and Linux. It
On Sun, Apr 15, 2012 at 6:18 PM, Victor Stinner victor.stin...@gmail.comwrote:
Here is a simplified version of the first draft of the PEP 418. The
full version can be read online.
http://www.python.org/dev/peps/pep-0418/
FYI there is no time.thread_time() function. It would only be
Here is a simplified version of the first draft of the PEP 418. The
full version can be read online.
http://www.python.org/dev/peps/pep-0418/
The implementation of the PEP can be found in this issue:
http://bugs.python.org/issue14428
The PEP is now fully ready: I just finished the
I'll do it. Give me a few days (tomorrow is fully booked with horrible
meetings).
On Tue, Apr 17, 2012 at 5:06 PM, Victor Stinner
victor.stin...@gmail.com wrote:
Here is a simplified version of the first draft of the PEP 418. The
full version can be read online.
This is becoming the Manhattan Project of bike sheds.
___
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%40mail-archive.com
2012/4/16 Matt Joiner anacro...@gmail.com:
This is becoming the Manhattan Project of bike sheds.
FreeBSD FAQ contains an entry Why should I care what color the
bikeshed is? which mention a sleep(1) should take fractional second
arguments saga in 1999.
On Mon, Apr 16, 2012 at 12:38:41PM +0200, Victor Stinner
victor.stin...@gmail.com wrote:
Bikeshedding is maybe a common issue with the discussion around time
function? :-)
Perhaps because everyone of us lives in a different Time-Space
Continuum? ;-)
Oleg.
--
Oleg Broytman
On Mon, 16 Apr 2012 01:25:42 +0200
Victor Stinner victor.stin...@gmail.com wrote:
I suppose that most people don't care that resolution and
precision are different things.
Don't they? Actually, they don't care about resolution since they
receive a Python float.
Regards
Antoine.
Here is a simplified version of the first draft of the PEP 418. The
full version can be read online.
http://www.python.org/dev/peps/pep-0418/
I wrote an implementation in pure Python using ctypes for Python 3.3:
https://bitbucket.org/haypo/misc/src/tip/python/pep418.py
I tested it on Linux,
Here is a simplified version of the first draft of the PEP 418. The
full version can be read online.
http://www.python.org/dev/peps/pep-0418/
FYI there is no time.thread_time() function. It would only be
available on Windows and Linux. It does not use seconds but CPU
cycles. No module or
Victor Stinner wrote:
Hi,
Here is a simplified version of the first draft of the PEP 418. The
full version can be read online.
http://www.python.org/dev/peps/pep-0418/
The implementation of the PEP can be found in this issue:
http://bugs.python.org/issue14428
I post a simplified
2012/4/15 M.-A. Lemburg m...@egenix.com:
I'd suggest to also include a tool or API to determine the
real resolution of a time function (as opposed to the advertised
one). See pybench's clockres.py helper as example.
The PEP includes such tool, but I forgot to mention it in the PEP:
34 matches
Mail list logo
