Paul Ganssle <p.gans...@gmail.com> added the comment: > The better is the enemy of the good here. Given the history of this issue, I > would rather accept a well documented restrictive parser than wait for a more > general code to be written. Note that we can always relax the parsing rules > in the future.
This is in fact the exact reason why I wrote the isoformat parser like I did, because ISO 8601 is actually a quite expansive standard, and this is the least controversial subset of the features. In fact, I spent quite a bit of time on adapting the general purpose ISO8601 parser I wrote for dateutil *into* one that only accepts the output of isoformat() because it places a minimum burden on ongoing support, so it's not really a matter of waiting for a more general parser to be written. I suggest that for Python 3.7 we *only* support output of isoformat(). Many general iso8601 parsers exist, including the one I have already implemented for python-dateutil (which will be part of the dateutil 2.7.0 release). We can have further discussion later about what exactly should be supported in Python 3.8, but even in the pre-release discussions I'm already seeing pushback about some of the more unusual 8601 formats, and it's a *lot* easier to explain (in documentation) that `fromisoformat()` is intended to be the inverse of `isoformat()` than it is to explain which variations of ISO 8601 are and are not supported (fractional minutes? if you're following the standard, the separator has to be a T, so what other variations of the standard are allowed?). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue15873> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
