
I'll leave typing details to typing-sig regulars, but I have a few comments “from outside”: Replying to the Discourse post (https://discuss.python.org/t/rfc-on-pep-681-data-class-transforms/14116):
The PEP will not affect CPython directly except for the addition of the dataclass_transform decorator in typing.py. The decorator is currently in typing_extensions.
Could this be also said in the PEP itself? It would be nice if e.g. a maintainer of Python's parser could read the introduction and decide to skip the rest & leave it to typing-sig. Including this note would also serve to better qualify phrases like "cannot", "error", "resulting behavior" throughout the PEP. I assume they specify expected behavior of type checkers, and don't apply at runtime. Is that right? And regarding that statement: Do you not plan to apply the decorator to dataclass itself? Will dataclasses.dataclass not get a __dataclass_transform__ attribute at runtime? Abstract:
PEP 557 introduced the dataclass to the Python stdlib.
IMO it would be better to link to the current documentation (https://docs.python.org/3.11/library/dataclasses.html) than to the 4-year-old document that first proposed adding dataclasses? The rationale and discussion around the proposal don't seem relevant, and the specification may be out of date. Same for later references to that PEP. And in general: Are the semantics expected to evolve if new features are added to dataclasses? Or to other popular libraries that work like dataclasses?