Paul Ganssle <p.gans...@gmail.com> added the comment:
> Defining isoformat() and fromisoformat() as functional inverses is misguided. > Indeed, it's not even true: `isoformat()` is not the inverse of `fromisoformat()`, that doesn't work because there are multiple strings that isoformat() can create from any given datetime. There is, however, only one datetime that is represented by any given datetime (assuming you consider truncation to create a new datetime), so it is fine for fromisoformat() to be the inverse of isoformat(). I have explained the reason that was chosen for the contract in several places (including in this thread), so I won't bother to repeat it. I think from a practical point of view we should eventually grow more generalized ISO 8601 parsing functionality, and the main question is what the API will look like. In dateutil.parser.isoparse, I still haven't figured out a good way to do feature flags. > I'd be willing to work on a PR, but a change of this size probably needs to > through python-ideas first? I don't think it *needs* to go to python-ideas, though it's probably a good idea to try and work out the optimal API in a post on the discourse ( discuss.python.org ), and the "ideas" category seems like the right one there. Please CC me (pganssle) if you propose modifications to the fromisoformat API on the discourse. ---------- _______________________________________ 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
