[Alexander Belopolsky] >> ... >> but I would really like to see a change in the repr of negative >> timedeltas: >> >> >>> timedelta(minutes=-1) >> datetime.timedelta(-1, 86340) >> >> And str() is not much better: >> >> >>> print(timedelta(minutes=-1)) >> -1 day, 23:59:00 >> >> The above does not qualify as a human readable representation IMO.
[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 > > 0 <= microseconds < 1000000 > 0 <= seconds < 60 > > (There is no such invariant for days -- they hold the sign bit.) > > In essence, you'd have to look at all three attributes to figure out on > which side of 0 is was (or think of the right way to do it, which is to > compare to timedelta(0)). I might still go for it, if it wasn't too late by > over a decade (as Tim says). Seems timedelta is over-specified, yes? For example, those invariants apply to CPython's internal representation, but have no direct effect on the set of representable timedeltas, and the constructor couldn't care less about them (other than to bash its inputs into those ranges; BTW, note that the invariant on `seconds` is actually < 86400, not < 60); e.g., >>> datetime.timedelta(days=1, seconds=1000000, microseconds=-3847384738473) datetime.timedelta(-32, 3815, 261527) So perhaps it would be better to document the practical truth ;-) That is, a timedelta is an integer number of microseconds in range(-86399999913600000000, 86400000000000000000) and all the rest is just more-or-less artificial complication due to choosing to _represent_ that range in a funky mixed-radix days/seconds/microseconds format. For >>> print(timedelta(minutes=-1)) I'd like to see: -00:01:00 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. Spelling out the units with keyword days/seconds/microseconds arguments would be fine, though. If I had it to do over, I'd _require_ keyword arguments on timedelta(). I don't know how often I've seen, e.g., timedelta(1), and didn't remember that "the first" argument is fortnights ;-) _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
