[Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions (original) (raw)

Guido van Rossum guido at python.org
Sun Apr 29 16:37:42 CEST 2012

On Sun, Apr 29, 2012 at 5:29 AM, Steven D'Aprano <steve at 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 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)

More information about the Python-Dev mailing list