PEP 681: Address Steering Council feedback (#2555)
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com> Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com> Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
This commit is contained in:
parent
4233ef7c88
commit
d40ca166d0
22
pep-0681.rst
22
pep-0681.rst
|
@ -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 dataclasses.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
@ -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.
|
||||
|
||||
Django does not support declaring fields using type annotations only,
|
||||
so Django users who leverage ``dataclass_transform`` should be aware
|
||||
|
@ -621,8 +622,8 @@ 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
|
||||
a ``cmp`` parameter, since it only applies to attrs. Users can emulate
|
||||
the ``cmp`` behaviour by using the ``eq`` and ``order`` parameter names
|
||||
instead.
|
||||
|
||||
Automatic field name aliasing
|
||||
|
@ -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 SQLAlchemy fields are optional, and ``None`` indicates that
|
||||
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
|
||||
|
@ -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
|
||||
==========
|
||||
|
|
Loading…
Reference in New Issue