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

[Guido van Rossum]

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)