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.

Sign up for GitHub

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: Decorator placement, future params, unstated semantics #2498

Merged
merged 3 commits into from
Apr 1, 2022
Merged

PEP 681: Decorator placement, future params, unstated semantics #2498

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d897f7b
Decorator placement, overloads, future params, unstated semantics
debonte Mar 31, 2022
5f13894
Language tweaks
debonte Apr 1, 2022
6ad6301
will -> may
debonte Apr 1, 2022
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
26 changes: 21 additions & 5 deletions pep-0681.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -78,6 +78,7 @@ 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.


Specification
=============

Expand All @@ -94,6 +95,10 @@ a class, endowing it with dataclass-like behaviors.

If ``dataclass_transform`` is applied to a function, using the decorated
function as a decorator is assumed to apply dataclass-like semantics.
If the function has overloads, the ``dataclass_transform`` decorator can
be applied to the implementation of the function or any one, but not more
than one, of the overloads.

If ``dataclass_transform`` is applied to a class, dataclass-like
semantics will be assumed for any class that derives from the
decorated class or uses the decorated class as a metaclass.
Expand Down Expand Up @@ -239,6 +244,11 @@ customization of default behaviors:
describing the stdlib dataclass behavior, we would provide the
tuple argument ``(dataclasses.Field, dataclasses.field)``.

In the future, we will add additional parameters to
debonte marked this conversation as resolved.
Show resolved Hide resolved
``dataclass_transform`` as needed to support common behaviors in user
code. These additions will be made after reaching consensus on
typing-sig rather than via additional PEPs.

The following sections provide additional examples showing how these
parameters are used.

Expand Down Expand Up @@ -473,8 +483,13 @@ For example:
Dataclass semantics
-------------------

The following dataclass semantics are implied when a function or class
decorated with ``dataclass_transform`` is in use.
Except where stated otherwise in this PEP, classes impacted by
``dataclass_transform``, either by inheriting from a class that is
decorated with ``dataclass_transform`` or by being decorated with
a function decorated with ``dataclass_transform``, are assumed to
behave like stdlib ``dataclass``.

This includes, but is not limited to, the following semantics:

* Frozen dataclasses cannot inherit from non-frozen dataclasses. A
class that has been decorated with ``dataclass_transform`` is
Expand Down Expand Up @@ -553,8 +568,9 @@ Undefined behavior
------------------

If multiple ``dataclass_transform`` decorators are found, either on a
single function/class or within a class hierarchy, the resulting
behavior is undefined. Library authors should avoid these scenarios.
single function (including its overloads), a single class, or within a
class hierarchy, the resulting behavior is undefined. Library authors
should avoid these scenarios.


Reference Implementation
Expand Down Expand Up @@ -684,7 +700,6 @@ support descriptor-typed fields. In fact it does, but type checkers
led to our misunderstanding. For more details, see the
`Pyright bug <#pyright-descriptor-bug_>`__.


``converter`` field descriptor parameter
----------------------------------------

Expand Down Expand Up @@ -724,6 +739,7 @@ References
.. _#class-var: https://docs.python.org/3/library/dataclasses.html#class-variables
.. _#pyright-descriptor-bug: https://github.com/microsoft/pyright/issues/3245


Copyright
=========

Expand Down