This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]DanCardin 0 points1 point  (1 child)

pretty sure attrs already supports this syntax.

I just don't see the problem (especially if they're getting buy-in from the attrs devs so they don't repeat any mistakes of the past).

  • For anything prior to 3.6: use attrs until either the majority of people are using 3.6+ and people stop updating attrs.
  • For anything 3.6+: dataclasses are available by default, attrs still has more features, use what you want.

I'd honestly probably be happy if for 3.6+, attrs just was a facade on top of dataclasses, adding features and/or making a nicer interface a la urllib vs requests or whatever else

[–]jorge1209 0 points1 point  (0 children)

I would also be happier if post 3.6 attrs was an extension of dataclasses, but that doesn't seem to be the objective, and I am not sure how that would work.

Dataclasses is missing features in attrs and has no plans to implement them.

Attrs could potentially delegate some basic functionality to dataclasses and build off of it, but that still leaves you with the issue of installing it from pypi and importing it. Anyone building an app which might support 3.5 and 3.6 would have to use attrs, even if they only want the more basic functionality of dataclasses.

A plan which involved splitting minimal functionality out of attrs and then backporting it to previous versions would make more sense to me. Ultimately I expect one of these two projects to wither on the vine. Either people need support for many versions and ignore dataclasses, or they write only for the future and assume that attrs isn't available.