GeezerVison

All commit authors signed the Contributor License Agreement.

I've added an explicit test matrix that doesn't rely on the hypothesis stubs. Feel free to ignore them as part of the review.

Is there a way to limit this to only the rfc3339 subset? The full set of iso8601 features is not always appropriate.

Is there a way to limit this to only the rfc3339 subset? The full set of iso8601 features is not always appropriate.

This sort of thing is the reason we delayed this expansion — the scope can easily grow if we do not constrain it to be something very specific, and we couldn't come up with a good way to allow users to express their preferences about what would be parsed. The approach we settled on is that fromisoformat would have a broad scope and not be configurable, and we will leave it to another library (or possibly another function) to allow further configuration.

I don't think it would be completely absurd to have a .fromrfc or fromrfc3339 method, though also RFC 3339 is so much more constrained than ISO 8601 that it's much easier to parse with something like a regex.

I don't think it would be completely absurd to have a .fromrfc or fromrfc3339 method, though also RFC 3339 is so much more constrained than ISO 8601 that it's much easier to parse with something like a regex.

Instead of adding yet another method - how about making the constructor accept a string? Many other builtin types have a constructor that accepts a single string argument and round-trips their __str__ (which may or may not be the same as their __repr__).

So my suggestion is for the constructor to accept the __str__ which is basically rfc3339 (possibly with a different separator) and the .fromisoformat() method would accept the larger set of ISO8601 values.

Ok, I think we're down to just nits and other things that can easily be taken care of after feature freeze. I'm going to merge this.