PEP 557 interop namespace

[micimize]

Extracted from #408 (comment)

On the other side of this, what about making a namespace that actually is intentionally similar to PEP 557 dataclasses and fields, and just has a thin adapter layer between field and attr.ib, etc? How much incompatibility is there beyond the names? Isn't attrs mostly a superset?

It would be good for migrating from large codebases where dataclasses are already used, or for pythonistas who want codebases/apis that stick close to the PEP specifications where possible.

[wsanchez]

I think that if we did that, we should have an attrs.dataclass namespace, rather than using the primary namespace.

The reason for that is that if we start down that path and set and expectations that Attrs is PEP 557 (plus whatever extra awesome) then (a) we might get cornered into design decisions made elsewhere in order to maintain this expectation (b) we might have used a name that conflicts with some future dataclass addition and (c) compatibility may require contortions that would be better contained in a compatibility namespace.

[micimize]

agreed – I think it should actually be attrs.dataclasses, such that migrating from the standard lib is just adding the prefix:
sed 's/from dataclasses import/from attrs.dataclasses import'

[asford]

This content likely belongs with the discussion in #565.

+1 to this idea, given what we've seen in #795, I think there are now more knock-on benefits than ever to adding a "dataclass compatible namespace".

A few potential benefits would include:

• Direct support for pyright et al via the dataclass_transform spec, which is now PEP 681
• A smooth upgrade path for codebases that see the light wish to adopt attrs features.
• A smooth "reverse compatibility" path for codebases using attrs, but need to interact with dataclass-ish libraries.

The goal of the namespace would be to provide an attrs mode that is superset of stdlib dataclasses,
where an application can update to attrs by just changing an import statement.
This falls into two branches: differences in behavior for existing features and features in dataclasses not supported in attrs.
A non-exhaustive index includes:

Differences for existing features are blocking changes that prevent an application from directly converting from dataclasses to attrs. This will require optional changes to attrs behavior and are "must have" for this proposed namespace:

• attrs private attributes handling, which strips leading underscores from member names.
• attrs field ordering during inheritance, perhaps, doesn't match the dataclasses ordering under inheritance

Missing features are non-blocking changes that would require an application to reduce their use of dataclasses features to convert to attrs. These could be implemented as additional attrs features and are "nice to have" for this proposed namespace:

• attrs supports __attrs_post_init__, rather than __post_init__.
• attrs does not support Init-only variables.
• attrs supports factory, but not default_factory, for default value factories.
• attrs does not support `KW_ONLY sentinel values.

[asford]

Notes on private attributes handling filed under #945.