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. :-)
The
dataclassesecosystem is growing rapidly. Currently, it's not easy for attrs classes to benefit from the developments in thedataclassesecosystem. It would be nice to fix this somehow.There are at least two use cases. One is where I write a class with
attrsthat holds aclass defined with
dataclasses. I want to be able to use all theattrsfunctionality.For example, the normally recursive function
attr.asdict()doesn'trecurse into dataclasses.
The other situation is where I want to use libraries developed for use with
dataclasseson my
attrsclasses. There are libraries which provide very useful functionality fordataclasses, but not forattrsclasses. For example, marshmallow_dataclass has some good ideas about serialization, and I might like to use it on myattrsclasses.Users of libraries that use
attrsanddataclasseswould benefit from easy interoperabilitybetween 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
ifstatementsThis 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 thedataclassesAPI as the common interface. This mightrestrict usage in some ways because
dataclasseshas less functionality thanattrs, but it could work relatively seamlessly. Alternatively, a shared compatibility interface could be defined in a third library, which could supportdataclasses,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
dataclassesandattrsso classes defined under one library can use the ecosystem written to support theother. 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. :-)