Natively support more types with pre-defined optional hooks

[makukha]

cattrs comes with a rich set of converters, but the variety of types supported by those converters out of the box is limited. Adding custom structure/unstructure hooks is pretty straightforward and well documented, and in most cases could be as trivial as in the example below. However, as an end user, I would be happy to have something even more simple, something that I wouldn't copy-paste from one project to another :)

A few ideas come to my mind:

1. What about adding a standalone function or a Converter method register_extra_hooks(converter, cls, structure=True, unstructure=True) (and its variant without first argument, defaulting to global_converter) that will cover less frequently used types from stdlib, like uuid, zoneinfo, ipaddress, re.Pattern, etc? This won't require any overhead in default case, but will enable one liner

register_extra_hooks(converter, ZoneInfo)

instead of

@converter.register_structure_hook
def structure_zoneinfo(value: Any, _) -> ZoneInfo:
    return ZoneInfo(str(value))

@converter.register_unstructure_hook
def unstructure_zoneinfo(value: ZoneInfo) -> str:
    return str(value)

2. This new function could be even generalized to accept multiple types, like

register_extra_hooks(IPv4Address, ZoneInfo)

3. It is possible to support non-stdlib modules in this function, by e.g. checking __module__ string or using inspect.getmodule() before importing third-party module itself.

4. Extra hooks could be registered by third-party libraries with e.g. pluggy.

Does anything of the mentioned above sound reasonable?

[Tinche]

I think it's a cool idea. cattrs already has the concept of strategies, so this would be an additional strategy (extra_stdlib_types, to be concise?).

If you're willing to contribute this, I'd be happy to provide guidance and reviews!

[makukha]

@Tinche hank you for your support, I'd be happy to work on this feature!

For the strategy name, I mentioned that existing strategies' names start with a verb:

• configure_tagged_union
• include_subclasses
• use_class_methods
• configure_union_passthrough

So what do you think about one of these names for the new strategy:

• register_extra_types
• configure_extra_types
• ???

I could start with few stdlib types, and then add support for arbitrary pluggable types to the same strategy.

[Tinche]

Sorry for the delayed response, hectic weeks at work.

Let's go with register_extra_types.

I could start with few stdlib types, and then add support for arbitrary pluggable types to the same strategy.

Sounds good. We should be careful not to go overboard with third party libraries, but some (like numpy maybe) I would be willing to support.