Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PEP 681: Address Steering Council feedback #2555

Merged
merged 3 commits into from
Apr 25, 2022
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 11 additions & 13 deletions pep-0681.rst
Original file line number Diff line number Diff line change
Expand Up @@ -80,6 +80,10 @@ sync will make it easier for dataclass users to understand and use
``dataclass_transform`` and will simplify the maintenance of dataclass
support in type checkers.

Additionally, we will consider adding ``dataclass_transform`` support
in the future for features that have been adopted by multiple
third-party libraries but are not supported by stdlib dataclass.
debonte marked this conversation as resolved.
Show resolved Hide resolved
debonte marked this conversation as resolved.
Show resolved Hide resolved


Specification
=============
Expand Down Expand Up @@ -607,10 +611,7 @@ annotations but with no assignment should be treated as data fields.

We considered supporting ``auto_attribs`` and a corresponding
``auto_attribs_default`` parameter, but decided against this because it
is specific to attrs and appears to be a legacy behavior. Instead of
supporting this in the new standard, we recommend that the maintainers
of attrs move away from the legacy semantics and adopt
``auto_attribs`` behaviors by default.
is specific to attrs and appears to be a legacy behavior.
debonte marked this conversation as resolved.
Show resolved Hide resolved

Django does not support declaring fields using type annotations only,
so Django users who leverage ``dataclass_transform`` should be aware
Expand All @@ -621,9 +622,9 @@ that they should always supply assigned values.

The attrs library supports a bool parameter ``cmp`` that is equivalent
to setting both ``eq`` and ``order`` to True. We chose not to support
a ``cmp`` parameter, since it only applies to attrs. Attrs users
should use the dataclass-standard ``eq`` and ``order`` parameter names
instead.
a ``cmp`` parameter, since it only applies to attrs. Users can work
around this limitation by using the dataclass-standard ``eq`` and
debonte marked this conversation as resolved.
Show resolved Hide resolved
``order`` parameter names instead.
debonte marked this conversation as resolved.
Show resolved Hide resolved

Automatic field name aliasing
-----------------------------
Expand Down Expand Up @@ -682,9 +683,9 @@ Class-wide default values
-------------------------

SQLAlchemy requested that we expose a way to specify that the default
value of all fields in the transformed class is None. It is typical
that all of their fields are optional, and None indicates that the
field is not set.
value of all fields in the transformed class is ``None``. It is typical
that all of SQLAlchemy fields are optional, and ``None`` indicates that
debonte marked this conversation as resolved.
Show resolved Hide resolved
the field is not set.

We chose not to support this feature, since it is specific to
SQLAlchemy. Users can manually set ``default=None`` on these fields
Expand Down Expand Up @@ -729,9 +730,6 @@ solution would be to add support for a ``converter`` field specifier
parameter but then use the ``Any`` type for the corresponding
parameter in the ``__init__`` method.

We chose not to support this feature and recommend that attrs users
avoid converters.


References
==========
Expand Down