Paul Ganssle <p.gans...@gmail.com> added the comment:
You can see the discussion in bpo-15873 for the full rationale of why "Z" was omitted - to quote from https://bugs.python.org/issue15873#msg307607 : > 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?) With the current implementation, the contract of the function is very simple to explain: datetime.fromisoformat() is the inverse operation of datetime.isoformat(), which is to say that every valid input to datetime.fromisoformat() is a possible output of datetime.isoformat(), and every possible output of datetime.isoformat() is a valid input to datetime.fromisoformat(). With that as the background - fromisoformat() was designed to be a conservative API because scope is a one-way ratchet, and it's better to under-commit than over-commit. We do have the option going forward of widening the scope of the function in a backwards-compatible way. The main problem I see is that I think we should maintain the property that it should be dead simple to explain what a function does, and having to enumerate edge cases is a code smell. So "it is the inverse operation of fromisoformat(), but it also supports specifying using Z for UTC" fails that test in my opinion. I see a few rational choices here: 1. Supports the full ISO 8601 datetime spec and all outputs from datetime.isoformat() (these inputs mostly but not completely overlap). We would then just have to decide on a simple policy for how to deal with the optional portions of the spec. 2. Support only the rfc3339 standard + the outputs of datetime.isoformat(), with the option to switch to #1 later. 3. Add the ability for `datetime.isoformat()` to output 'Z' instead of `00:00`, which would allow us to support it as an input and also keep the scope of `datetime.fromisoformat` unchanged. 4. Add a separate function (either a classmethod or a bare function) for parsing exactly the ISO 8601 standard, maybe `parse_iso8601`, so both `parse_iso8601` and `fromisoformat` have a clean, rational explanation for what they do. 5. Leave the current scope alone and don't add anything. 5a. Leave the current scope alone and point people in the direction of `dateutil.parser.isoparse` in the documentation. ---------- _______________________________________ 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
