python-attrs / python-attrs/attrs
Interoperability with dataclasses
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 5.8k
- Forks
- 480
- Avg merge
- 2h 15m
- Merged PRs (30d)
- 2
Description
The dataclasses ecosystem is growing rapidly. Currently, it's not easy for attrs classes to benefit from the developments in thedataclasses ecosystem. It would be nice to fix this somehow.
There are at least two use cases. One is where I write a class with attrs that holds a
class defined with dataclasses. I want to be able to use all the attrs functionality.
For example, the normally recursive function attr.asdict() doesn't
recurse into dataclasses.
@dataclasses.dataclass
class A:
x: int
@attr.dataclass
class B:
a: A
In [5]: B(A(1))
Out[5]: B(a=A(x=1))
In [6]: attr.asdict(B(A(1)))
Out[6]: {'a': A(x=1)}
The other situation is where I want to use libraries developed for use with dataclasses
on my attrs classes. There are libraries which provide very useful functionality for
dataclasses, but not for attrs classes. For example, marshmallow_dataclass has some good ideas about serialization, and I might like to use it on my attrs classes.
Users of libraries that use attrs and dataclasses would benefit from easy interoperability
between the two systems. I've been wondering how to make this work.
Supporting both systems explicitly in every library
One solution would be to edit each of these functions to support both systems, by adding if statements
def asdict(cls):
if attr.has(cls):
...
if dataclasses.is_dataclass(cls):
...
This might need to be done in each library that intends to support both systems.
Supporting both systems implicitly in every library through an interface
It might be possible to support both systems through a common interface. For example, if
attrs classes got __dataclasses_params__ and __dataclasses_fields__ in addition to
__attrs_attrs__, using the dataclasses API as the common interface. This might
restrict usage in some ways because dataclasses has less functionality than attrs, but it could work relatively seamlessly. Alternatively, a shared compatibility interface could be defined in a third library, which could support dataclasses, attrs, and any other libraries that come to provide similar declarative-class-definition functionality.
Converting between attrs and dataclasses
Perhaps it would be useful to have a function for converting between dataclasses and
attrs so classes defined under one library can use the ecosystem written to support the
other. There would be nuances involved with making classes round-trippable since each
library supports different functionality.
I'm interested in everybody's thoughts on how to handle this situation. :-)
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 issue's two interoperability use cases: recursive attr.asdict() handling of dataclasses and using dataclass-oriented libraries with attrs classes. Compare the proposed common interface and conversion approaches, then clarify a concrete, testable scope with maintainers. Done requires an agreed direction and defined compatibility behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- developer-experience
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100