Paul Ganssle <p.gans...@gmail.com> added the comment:
> It seems a little odd to need to pull in a third-party library for this; it
> seems far more tempting for me to just do
> "datetime.fromisoformat(str.replace('Z', '+00:00'))" instead since I know my
> dates are produced by a JSON API.
Yes, this is also a viable solution. Generally speaking, third party libraries
are less onerous these days than they have been in the past, and there are many
things that are delegated to third party libraries because staying out of the
standard library gives more flexibility in release cycles and the APIs don't
need to be quite as stable.
> FWIW, I do think that fromisoformat() is the right function to provide
> RFC3339 support. I don't think
> users would benefit from having to choose between several different functions
> that parse similar but
> subtly different date formats; this seems likely to cause confusion.
This is in fact one of the reasons to proceed with caution here, because ISO
8601, RFC 3339 and datetime.isoformat() are three slightly different and in
some senses *incompatible* datetime serialization formats. If I had the choice,
I would probably either not have named `isoformat` the way it is named, or I
would have stuck to the standard, but what's done is done. As it is now, all
the "fromX" alternate constructors are simply the inverse operation of the
corresponding "X" method. If we make fromisoformat accept the RFC 3339 subset
of ISO 8601, people will find it confusing that it doesn't support even some of
the most common *other* ISO 8601 formats, considering it's called
`fromisoformat` not `fromrfcformat`.
To give you an idea of why this sort of thing is a problem, it's that with each
minor change, expanding the scope a little sounds reasonable, but along with
that comes maintenance burdens. People start to rely on the specific behavior
of the function, and eventually you get into a position where someone asks for
a very reasonable expansion of the scope that is incompatible with the way
people are already using the function. This leads you to either stop developing
the function at some arbitrary point or to start tacking on a configuration API
to resolve these incompatibilities.
If instead we design the function from the beginning with a very clear scope,
we can also design the configuration API (and the default values) from the
beginning as well. I definitely believe there is a place for a function that
parses at least the timestamp portions of the ISO 8601 spec in CPython. I think
I would prefer it to be a separate function from fromisoformat. I also think
that it's worth letting it marinate in dateutil a bit, so that we can get a
sense of what works and what doesn't work as a configuration API so that it's
at least *easier* for people to select which of the subtly different datetime
formats they're intending to parse.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35829>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
