On Sat, 22 Aug 2020 at 13:08, Oz <nahu...@gmail.com> wrote:
>
> 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
_______________________________________________
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/4COOYUTWO2VCQV5C6N2YRFZUCPKJG7A3/
Code of Conduct: http://python.org/psf/codeofconduct/
