My goal for the isoparser in the future is to allow more customization of the parse to allow the user to be more or less strict than the ISO 8601 standard, but I think it's time to get the 2.7.0 release out the door, so I've tweaked the documentation to indicate that the strictness of the default isoparse is not something to rely on (until the strictness can be specified).

Additionally, in a nod to pragmatism (since a huge number of people use ISO 8601 with a space separator rather than a T separator), I've relaxed the strictness of the parser to accept any single ASCII character by default, rather than just T. This brings the behavior more in line with the forthcoming datetime.fromisoformat alternate constructor - though there are things fromisoformat accepts that this function won't, and things this function accepts that fromisoformat won't, for the majority of people dateutil.parser.isoparse will work perfectly well as a substitute for datetime.fromisoformat.