This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, martin.panter, musically_ut, r.david.murray, serhiy.storchaka, vstinner
Date 2017-07-02.17:40:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1499017231.76.0.110059138926.issue30302@psf.upfronthosting.co.za>
In-reply-to
Content
Sorry for being late to the discussion, but please allow me to add a -1 vote. The time.struct_time precedent is indeed comically verbose.  Whenever I need to inspect a struct_time, I cast it to a plain tuple

Compare

>>> time.gmtime(1121871596)
time.struct_time(tm_year=2005, tm_mon=7, tm_mday=20, tm_hour=14, tm_min=59, tm_sec=56, tm_wday=2, tm_yday=201, tm_isdst=0)

and

>>> time.gmtime(1121871596)[:]
(2005, 7, 20, 14, 59, 56, 2, 201, 0)

Unless you need to know what the last three fields are, the long form gives no advantage.

datetime.timedelta(days=3114, seconds=28747, microseconds=100000) is not as verbose and the extra information may be helpful the first time you see it, but if you deal with timedeltas a lot, it would quickly become annoying. Moreover, unlike in the struct_time case, there will be no easy way to suppress metadata.

Furthermore, "seconds=28747" is not that user-friendly. A friendlier representation would be "hours=7, minutes=59, seconds=7" and similar information is displayed when you print a timedelta:

>>> datetime.timedelta(days=3114, seconds=28747, microseconds=100000)
datetime.timedelta(3114, 28747, 100000)
>>> print(_)
3114 days, 7:59:07.100000
History
Date User Action Args
2017-07-02 17:40:31belopolskysetrecipients: + belopolsky, vstinner, r.david.murray, martin.panter, serhiy.storchaka, musically_ut
2017-07-02 17:40:31belopolskysetmessageid: <1499017231.76.0.110059138926.issue30302@psf.upfronthosting.co.za>
2017-07-02 17:40:31belopolskylinkissue30302 messages
2017-07-02 17:40:31belopolskycreate