On Sat, 22 Aug 2020 at 13:08, Oz
Hi Everyone,
I really like how go parses durations:
``` hours, _ := time.ParseDuration("10h") complex, _ := time.ParseDuration("1h10m10s") micro, _ := time.ParseDuration("1µs") // The package also accepts the incorrect but common prefix u for micro. micro2, _ := time.ParseDuration("1us") ```
Consider the example in https://docs.python.org/3/library/datetime.html#timedelta-objects: ```
from datetime import timedelta delta = timedelta( ... days=50, ... seconds=27, ... microseconds=10, ... milliseconds=29000, ... minutes=5, ... hours=8, ... weeks=2 ... )
With a go like parsing it would be:
datetime.parse_duration("2w50d8h5m27s10ms2000us")
In the context you present, it looks like the expected use case is almost exclusively parsing constant strings representing fixed timedeltas. In that context, it seems to me that we have: pros: more compact (not everyone would view this as a "pro", but let's go with it). cons: overhead of string parsing at runtime more potential errors (mistype w as q, for example) new syntax to remember (do the parts need to be in a particular order, are spaces allowed, is it us or μs, etc?) Overall, I don't think this is particularly beneficial, personally. If on the other hand you're expecting to parse *non-constant* strings, you're typically talking about user-entered data. In which case, it seems like you're inventing a new, fairly limited, notation for time intervals, with the expectation that it would be used in places like config files, or maybe even direct user input. So the proposal depends heavily on whether the notation is something people would want. And in that case, I think it's unlikely. I'd be much more supportive if this were a well-known standard format for intervals. It appears that ISO 8601 defines such a format - see https://en.wikipedia.org/wiki/ISO_8601#Durations. Maybe the Go notation is somehow better, but there's no immediate reason I can see to assume that. And for human input, you'd want something a lot more flexible. People typically don't enter things in nice neat formats, and parsers need a lot of flexibility. That's quite messy, and the stdlib typically isn't where such parsers are available (parsing of human date input is found in external libraries like dateutil, the stdlib sticks to more fixed formats). To be honest, there doesn't seem to be much around in the way of parsers for interval data, so it would be nice to see something. But (a) I'd rather it were on PyPI, so it's not restricted to newer versions of Python, and (b) the proposed format isn't one I'd want, personally. Paul