Open energizah opened 4 years ago
Well this is obviously a multi-tiered problem. I'm personally happy about having some kind of interop with DCs, since they are quite similar and everyone would win.
I think asdict
would be best served by converting it into something singledispatch-based on Python 3+. That would give people a lot more flexibility for free. We could just use the old version on Python 2 and write a brand new one for 3+.
Would everything "just work" if we had a fallback thing for fields
? singledispatch
for extensibility seems like a good way to go, but I wouldn't want to have to explicitly register every dataclass in the world.
@glyph you mean like a special case for dataclasses.is_dataclass
? Sure why not.
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 withdataclasses
. I want to be able to use all theattrs
functionality.For example, the normally recursive function
attr.asdict()
doesn't recurse into dataclasses.The other situation is where I want to use libraries developed for use with
dataclasses
on myattrs
classes. There are libraries which provide very useful functionality fordataclasses
, but not forattrs
classes. For example, marshmallow_dataclass has some good ideas about serialization, and I might like to use it on myattrs
classes.Users of libraries that use
attrs
anddataclasses
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
statementsThis 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 thedataclasses
API as the common interface. This might restrict usage in some ways becausedataclasses
has 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
dataclasses
andattrs
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. :-)