Add new strategy register_extra_types

[makukha]

Contribution to #641.

Converters supported:

• BaseConverter, Converter, all preconfigured converters

Extra types added:

• complex
• uuid.UUID
• zoneinfo.ZoneInfo

More extra types to be added in this pull request:

• array.array
• datetime: date, datetime (not supported by raw BaseConverter and Converter)
• datetime: time, timedelta
• decimal.Decimal
• fraction.Fraction
• ipaddress: ...
• numbers: Complex, Real, Rational, Integral
• numpy: ...
• pathlib.Path
• re.Pattern

[makukha]

@Tinche sorry for the long delay, had to complete some work. Could you please take a look at this draft? It must have flaws, so please feel free to suggest or make any changes. I added a couple of tests, but probably missed some important test cases. It is a pleasure to work on cattrs codebase :)

[Tinche]

My baby's sleep regression is kicking my ass so I'm also going to ask for some patience 😇

From what I understand, the api is supposed to be register_extra_types(converter, UUID)? How about we make it register_extra_types(converter, uuid=True)?

Doesn't require an import, gets auto complete, a little more discoverable?

[makukha]

Thank you for finding time for this feature! I wish health and strength to you and your family.

For the API design, I was keeping in mind future extensibility with user plugins, so that register_extra_types needs to support an unbounded collection of types. Also, passing types as args explicitly will save user from guessing what specific types are covered by e.g. numpy= kwarg, just in case numpy adds new ones in future, or we will be adding them gradually. With explicit type arguments, error will be raised on import rather than at the run time.

I use cattrs for both config management and sequential processing of datasets. In my use cases, I always have separate file config.py or model.py where I declare the model. I still need to import all the types for annotations, and register_extra_types will be called in this same file. Do you have a different use case?

If you are still confident that kwarg-based approach is better, I have no objections to follow this direction until register_extra_types starts supporting third-party hooks via plugins.