Oz writes:
> With a go like parsing it would be:
> ```
> >>> datetime.parse_duration("2w50d8h5m27s10ms2000us")
-1 I see no need for this, and minutes vs. months are ambiguous.
Especially with denormalized input as above, it's quite unreadable
compared to the timedelta constructor with keywords. I suspect it's
mistake-prone.
If it is to be used for user input, I think consideration should be
given to internationalization (e.g., all of the Japanese units except
hours are single character characters, and hours can be abbreviated
intuitively and unambiguously which is more than you can say for
English months, minutes, milliseconds, and microseconds!) But that
degree of complexity is pretty clearly out of scope for the standard
library. There probably should be an option for warning or raising on
denormalized input. That is, it's OK to omit units that could be
used, but not to overflow to the next bigger unit actually used. So
"8h300s" would be OK, but "8h4300s" not. Also, a warning if the units
are out of order. Again, that kind of thing seems like it never ends
and is beyond the scope of the standard library.
If anything is to be added, I would prefer using ISO 8601 durations.
https://en.wikipedia.org/wiki/ISO_8601#Durations
The main differences are use of "P" and "T" to signal that it is a
duration and allow both minutes and months to be identified by "M",
and decimal fractions of the smallest unit present are permitted, and
seconds is the smallest unit, so the above would be represented
"P2W50DT8H5M27.012000S"
Since conversions among s, ms, and μs are just 3 place decimal
shifts, I don't see a desperate need for separate unit symbols for
those.
There are some useful extensions that would not make parsing more
difficult. I don't see any reason to disallow lower case or mixed
case, and in most fonts I would find lowercase more readable. Perhaps
both ASCII SPC and underscore ('_') could be ignored, for better
readability. This would also help future-proof against extensions to
datetime to allow nanoseconds (or arbitrary SI prefixes), and (at
least up to nanoseconds) quite readable with the recent Python
convention allowing "_" to group digits in numbers.
Steve
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/VYCCT2KFA5YESEKMMO7GFA46DQSZWXPV/
Code of Conduct: http://python.org/psf/codeofconduct/
