From d40ca166d0a10473b636e755a03a153cbd32f78a Mon Sep 17 00:00:00 2001 From: Erik De Bonte Date: Mon, 25 Apr 2022 16:20:22 -0700 Subject: [PATCH] PEP 681: Address Steering Council feedback (#2555) Co-authored-by: Jelle Zijlstra Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com> Co-authored-by: Alex Waygood --- pep-0681.rst | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/pep-0681.rst b/pep-0681.rst index 386e481c798..e26a82c5fdb 100644 --- a/pep-0681.rst +++ b/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 ==========