Mailing List Archive: Python: Dev

[RFC] PEP 418: Add monotonic time, performance counter and process time functions

1 2

View All

Index | Next | Previous | View Threaded

eric at trueblade

Apr 28, 2012, 4:20 PM

Post #26 of 37 (152 views)
Permalink

Re: [RFC] PEP 418: Add monotonic time, performance counter and process time functions [In reply to]

On 4/27/2012 11:40 PM, Guido van Rossum wrote:
> On Fri, Apr 27, 2012 at 5:50 PM, Steven D'Aprano <steve [at] pearwood> 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 discussion, so this isn't a
comment on any time functions specifically.

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.

Same for sys.flags, although it's its own type, not a structseq. It is
also indexable, and we've added fields to it (hash_randomization was
added in 2.7.3).

So I think a structseq would work for get_clock_info as well. It's
unfortunate we don't have a similar type which isn't a tuple, but the
types we do have work well enough in practice.

Eric.
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

victor.stinner at gmail

Apr 28, 2012, 6:21 PM

Post #27 of 37 (150 views)
Permalink

Re: [RFC] PEP 418: Add monotonic time, performance counter and process time functions [In reply to]

>>> 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 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.

Ok ok, I changed the is_adjusted flag to make it mandatory and I
changed get_clock_info() to return a clock_info object. clock_info is
a structseq.

I didn't mention that clock_info can be read using an index because I
really don't like the tuple-like API.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

victor.stinner at gmail

Apr 28, 2012, 6:26 PM

Post #28 of 37 (151 views)
Permalink

Re: [RFC] PEP 418: Add monotonic time, performance counter and process time functions [In reply to]

Hi Guido,

2012/4/28 Guido van Rossum <guido [at] python>:
> 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 contributors,
> especially those who ended up as co-authors. We will have an awesome
> new set of time APIs! Now let the implementation roll...

The PEP is not accepted yet at:
http://www.python.org/dev/peps/pep-0418/

Did you forget to update its status, or are you waiting for something?

Anyway I commited the implementation of the PEP 418 (after the last
change on the API of time.get_clock_info()). Let's see how buildbots
feel with monotonic time.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

larry at hastings

Apr 29, 2012, 1:41 AM

Post #29 of 37 (152 views)
Permalink

Re: [RFC] PEP 418: Add monotonic time, performance counter and process time functions [In reply to]

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 not a tuple / structseq. There's no
need for the members to be iterable.

//arry/

eric at trueblade

Apr 29, 2012, 2:01 AM

Post #30 of 37 (149 views)
Permalink

Re: [RFC] PEP 418: Add monotonic time, performance counter and process time functions [In reply to]

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 structseq.
>
> 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. A
quick check shows sys.flags, sys.float_info, and os.stat(); I'm sure
there's more.

Iteration for these isn't very useful, but structseq is the handiest
type we have:

>>> for v in sys.float_info:
... print(v)
...
1.79769313486e+308
1024
308
2.22507385851e-308
-1021
-307
15
53
2.22044604925e-16
2
1

For python code I use namedtuple (or my own recordtype), which are
iterable but almost no one iterates over them.

Eric.
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

larry at hastings

Apr 29, 2012, 2:12 AM

Post #31 of 37 (149 views)
Permalink

Re: [RFC] PEP 418: Add monotonic time, performance counter and process time functions [In reply to]

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 isn't very useful, but structseq is the handiest
> type we have:

The times, they are a-changin'. I've been meaning to start whacking the
things which are iterable which really shouldn't be. Like, who uses
destructuring assignment with the os.stat result anymore? Puh-leez,
that's so 1996. That really oughta be deprecated.

Anyway, it'd be swell if we could stop adding new ones. Maybe we need a
clone of structseq that removes iterability? (I was thinking, we could
hack structseq so it didn't behave iterably if n_in_sequence was 0.
But, no, it inherits from tuple, such shenanigans are a bad idea.)

//arry/

p.s. MvL gets credit for the original observation, and the suggestion of
deprecating iterability. As usual I'm standing on somebody else's
shoulders.

steve at pearwood

Apr 29, 2012, 5:29 AM

Post #32 of 37 (146 views)
Permalink

Re: [RFC] PEP 418: Add monotonic time, performance counter and process time functions [In reply to]

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 iterable.
>> I agree with you, but there's already plenty of precedent for this.
>> [...] Iteration for these isn't very useful, but structseq is the
>> handiest
>> type we have:
>
> The times, they are a-changin'. I've been meaning to start whacking the
> things which are iterable which really shouldn't be. Like, who uses
> destructuring assignment with the os.stat result anymore? Puh-leez,
> that's so 1996. That really oughta be deprecated.

Why? What problems does it cause?

If it isn't broken, don't break it.

--
Steven

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

solipsis at pitrou

Apr 29, 2012, 5:38 AM

Post #33 of 37 (145 views)
Permalink

Re: [RFC] PEP 418: Add monotonic time, performance counter and process time functions [In reply to]

On Sun, 29 Apr 2012 02:12:41 -0700
Larry Hastings <larry [at] 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 iterable.
> > I agree with you, but there's already plenty of precedent for this.
> > [...] Iteration for these isn't very useful, but structseq is the handiest
> > type we have:
>
> The times, they are a-changin'. I've been meaning to start whacking the
> things which are iterable which really shouldn't be. Like, who uses
> destructuring assignment with the os.stat result anymore? Puh-leez,
> that's so 1996. That really oughta be deprecated.

Some types can benefit from being hashable and having a minimal
footprint (hence tuple-like). However it's not the case for
get_clock_info(), since you're unlikely to have more than one instance
alive in a given invokation.

Regards

Antoine.

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

solipsis at pitrou

Apr 29, 2012, 5:39 AM

Post #34 of 37 (143 views)
Permalink

Re: [RFC] PEP 418: Add monotonic time, performance counter and process time functions [In reply to]

On Sun, 29 Apr 2012 03:26:26 +0200
Victor Stinner <victor.stinner [at] gmail> wrote:

> Hi Guido,
>
> 2012/4/28 Guido van Rossum <guido [at] python>:
> > 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 contributors,
> > especially those who ended up as co-authors. We will have an awesome
> > new set of time APIs! Now let the implementation roll...
>
> The PEP is not accepted yet at:
> http://www.python.org/dev/peps/pep-0418/
>
> Did you forget to update its status, or are you waiting for something?
>
> Anyway I commited the implementation of the PEP 418 (after the last
> change on the API of time.get_clock_info()). Let's see how buildbots
> feel with monotonic time.

Hopefully they'll be monotonously green!

cheers

Antoine.

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

guido at python

Apr 29, 2012, 7:37 AM

Post #35 of 37 (142 views)
Permalink

Re: [RFC] PEP 418: Add monotonic time, performance counter and process time functions [In reply to]

On Sun, Apr 29, 2012 at 5:29 AM, Steven D'Aprano <steve [at] pearwood> 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 iterable.
>>>
>>> I agree with you, but there's already plenty of precedent for this.
>>> [...] Iteration for these isn't very useful, but structseq is the
>>> handiest
>>> type we have:
>>
>>
>> The times, they are a-changin'. �I've been meaning to start whacking the
>> things which are iterable which really shouldn't be. �Like, who uses
>> destructuring assignment with the os.stat result anymore? �Puh-leez, that's
>> so 1996. �That really oughta be deprecated.
>
>
> Why? What problems does it cause?
>
> If it isn't broken, don't break it.

It's an anti-pattern. You basically have to look up or copy/paste the
order of the fields to get it right. And there are many fields in the
stats structure that can't be added to the sequence because of the
requirement not to break backwards compatibility with code that
expects a fixed number of fields (in 1996 we also didn't have *
unpacking :-). So you're getting a legacy-determined subset of the
values anyway.

Ditto for times; while the first 6 fields are easy (y/m/d h/m/s) the
three after that are just fluff (weekday and some tz related things
that I can never remember) and again there is important stuff missing
like finer precision and useful tz info.

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

guido at python

Apr 29, 2012, 7:40 AM

Post #36 of 37 (143 views)
Permalink

Re: [RFC] PEP 418: Add monotonic time, performance counter and process time functions [In reply to]

On Sat, Apr 28, 2012 at 6:26 PM, Victor Stinner
<victor.stinner [at] gmail> wrote:
> Hi Guido,
>
> 2012/4/28 Guido van Rossum <guido [at] python>:
>> 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!

I tried to imply that in the next sentence. :-) Still, without your
push it would not have happened.

>> Also thanks to the many other contributors,
>> especially those who ended up as co-authors. We will have an awesome
>> new set of time APIs! Now let the implementation roll...
>
> The PEP is not accepted yet at:
> http://www.python.org/dev/peps/pep-0418/
>
> Did you forget to update its status, or are you waiting for something?

To get to a machine with a checkout. Done.

> Anyway I commited the implementation of the PEP 418 (after the last
> change on the API of time.get_clock_info()). Let's see how buildbots
> feel with monotonic time.

Awesome!

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

guido at python

Apr 29, 2012, 7:49 AM

Post #37 of 37 (143 views)
Permalink

Re: [RFC] PEP 418: Add monotonic time, performance counter and process time functions [In reply to]

On Sat, Apr 28, 2012 at 1:32 PM, Victor Stinner
<victor.stinner [at] gmail> 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 does this mean clock_gettime and friends only exist on
>> POSIX? Shouldn't they be in the os or posix module then? I guess I'm
>> fine with either place but I don't know if enough thought was put into
>> the decision. Up until now the time module had only cross-platform
>> functions (even if clock()'s semantics vary widely).
>
> The os module is big enough. Low level networks functions are not in
> the os module, but in the socket module.

There are subtle other reasons for that (such as that on Windows,
socket file descriptors and os file descriptors are different things).

But I'm fine with leaving these in the time module.

> Not all functions of the time module are always available. For
> example, time.tzset() is not available on all platforms. Another
> example, the new time.monotonic() is not available on all platforms
> ;-)
>
> Oh, I forgot to mention that time.clock_*() functions are not always
> available in the doc.

Yeah, I think the docs can use some work Maybe from someone interested
in contributing to docs specifically? I don't want to make Victor
responsible for everything. But the new docs for the time module are a
but confusing due to the explosion of new functions and constants.
E.g. several descriptions use 'clk_id' without explaining it. Maybe a
separate subsection can be created for low-level and/or
platform-specific items, leaving the main time module to explain the
traditional functions and the new portable functions from PEP 418?

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads