python-attrs / python-attrs/cattrs
Natively support more types with pre-defined optional hooks
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.1k
- Forks
- 159
- Avg merge
- 12h 21m
- Merged PRs (30d)
- 6
Description
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:
- What about adding a standalone function or a
Convertermethodregister_extra_hooks(converter, cls, structure=True, unstructure=True)(and its variant without first argument, defaulting toglobal_converter) that will cover less frequently used types from stdlib, likeuuid,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)
- This new function could be even generalized to accept multiple types, like
register_extra_hooks(IPv4Address, ZoneInfo)
-
It is possible to support non-stdlib modules in this function, by e.g. checking
__module__string or usinginspect.getmodule()before importing third-party module itself. -
Extra hooks could be registered by third-party libraries with e.g.
pluggy.
Does anything of the mentioned above sound reasonable?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the Converter hook-registration APIs and global_converter, then compare the proposed register_extra_hooks variants for stdlib types such as uuid, zoneinfo, ipaddress, and re.Pattern. Done means the scope and registration behavior are agreed, including whether multiple types and third-party hooks are supported; no test path is named in the issue.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100