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 vstinner
Recipients belopolsky, martin.panter, musically_ut, r.david.murray, serhiy.storchaka, tim.peters, vstinner
Date 2017-07-25.21:50:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1501019410.51.0.738070575839.issue30302@psf.upfronthosting.co.za>
In-reply-to
Content
This issue has a long history starting in 2015 with a thread on python-dev. Many messages were written on python-dev and on this issue. I will try to summarize. (I hate doing that, summarizing is a risk of missing important information or misunderstand someone.)

The issue opens multiple questions:

* Should we change repr?
** YES, Guido: "I still think the repr change to use keywords has a good chance for 3.6." and "Still, I can't be the only one to ever have been fooled by this, and it is definitely pretty arcane knowledge what the positional arguments to timedelta()."
** YES, Martin Panter: "I disagree that the positional timedelta parameters are well-known."
** YES, Victor Stinner
** NO, Tim Peter: "But I wouldn't change repr() - the internal representation is fully documented, and it's appropriate for repr() to reflect documented internals as directly as possible."
** NO, Serhiy: "The drawback is that this change increases the length of the repr. Users of datetime.timedelta know what arguments mean. If they don't know they always can look in the documentation or builtin help."
** NO, Alexander Belopolsky: msg297521 

* Can changing repr break code?
** Guido: when we randomized hash, a lot of tests failed

* Add a "-" prefix for negative result: -timedelta(seconds=1)?
* (Related) Should repr(timedelta(seconds=60)) returns 'timedelta(minutes=1)'?
** NO, Guido: "I'm sure that one often catches people by surprise. However, I don't think we can fix that one without also fixing the values of the attributes -- in that example days is -1 and seconds is 86340 (which will *also* catch people by surprise). And changing that would be much, much harder for backwards compatibility reasons-- we'd have to set days to 0 and seconds to -60, and suddenly we have a much murkier invariant, instead of the crisp"
** NO, Guido: "Then please just trust me. If the repr() shows different numbers than the attributes things are worse than now. People will casually look at the repr() and assume they've seen what the attributes will return, and spend hours debugging code that relies on that incorrect assumption."
** NO, R. David Murray : "I'm with Haypo: the repr should show the *actual* value of the attributes."
** NO, Victor Stinner: "Don't make repr() implementation overcomplicated (...) use str()"

Another remark of Alexander Belopolsky:

* "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: (...)"
** IHMO you should use str() and not repr() to format a value for humans. repr() is more designed for developers, to debug.

Another interesting remark: the documentation of the constructor is incomplete and should be document parameters.
History
Date User Action Args
2017-07-25 21:50:10vstinnersetrecipients: + vstinner, tim.peters, belopolsky, r.david.murray, martin.panter, serhiy.storchaka, musically_ut
2017-07-25 21:50:10vstinnersetmessageid: <1501019410.51.0.738070575839.issue30302@psf.upfronthosting.co.za>
2017-07-25 21:50:10vstinnerlinkissue30302 messages
2017-07-25 21:50:10vstinnercreate