Due to unfortunate naming, this is impractical — the full ISO-8601 format is large with arcane options like ordinal days, decimal fractions on minutes and much more. We can safely assume this will never happen in stdlib. I’m not sure any of the external packages that tried ever implemented 100% of the full standard. dateutil doesn’t either (doc says it doesn’t parse fractional minutes). A couple years ago I searched several other languages too, and didn’t find anybody doing full 8601! [I guess being a pay-to-read standard, with long prose and no BNF, makes this a goal programmers just don’t care enough about…]
What most people actually mean when they think “ISO” is “as long as I pass a valid RFC-3339 string”.
It’s a 1.3MB dependency that for many of us only adds one feature: the ability to parse the letter Z.
To be fair, there are multiple smaller modules that don’t attempt ISO 8601 but only RFC 3339 (not sure if any of them is perfect, but hey if not, let’s perfect one before requesting stdlib does it 
):
Let’s see, what are the actual points separating fromisoformat from full RFC 3339?
-
“Z” or lowercase “z” — @blacklight86 note you code above doesn’t handle “z”.
-
4.3. Unknown Local Offset Convention.
Not clear how to best represent withdatetime.
email.utils.parsedate_to_datetime set a precedent of returning a naive datatime, which you should understand as “UTC but with no indication of the actual source timezone”, which is… meh. -
Leap seconds (section 5.7)?
-
Conversely,
fromisoformatseems to accept any character between date and time. Even a digit.
Even\x00! Makes sense becauseisoformattakes an optional arg to emit any characters (space" "is common but not only). But a “from RFC” function better only allow"T","t", and optionally" "?
While I respectfully disagree on value of supporting RFC3339, this is a very insightful comment, thanks.