Hi,
Side note: it would be nice to add "typing: " prefix or mention "type
annotation" or "type check" in the title of PEPs which are about that.
Just from the PEP title, it's hard *for me* to guess that it's about
type annotations.
Examples of other PEP titles which confused me:
PEP 612 – Parameter Specification Variables
PEP 645 – Allow writing optional types as x?
PEP 646 – Variadic Generics
PEP 647 – User-Defined Type Guards
PEP 673 – Self Type
PEP 675 - Arbitrary Literal String Type
PEP 677 – Callable Type Syntax
First, I understood that "Arbitrary Literal String Type" was adding a
new built-in types for "literal strings" :-) Nope. It's just about
type annotations ;-)
From what I understood, the purpose of these PEPs outside type
annotations is limited or non existent :-)
Victor
On Mon, Jun 6, 2022 at 2:51 PM Petr Viktorin
Hello, With the latest wording changes, PEP 681 – Data Class Transforms is now fully accepted. Feel free to mark it as such at your convenience.
Happy typing, — Petr, on behalf of the Steering Council
On 23. 04. 22 13:26, Petr Viktorin wrote:
Hello, As an initial implementation that will be improved in the future, the specification in PEP 681 is fine. Feel free to add the decorator to Python 3.11 at your convenience.
However, the PEP includes several worrying recommendations like:
- we recommend that the maintainers of attrs move away from the legacy semantics and adopt auto_attribs behaviors by default. - We chose not to support this feature and recommend that attrs users avoid converters. - Attrs users should use the dataclass-standard eq and order parameter names instead.
These are probably meant as recommendations from typing-sig, but an accepted PEP represents consensus of the entire Python community. A typing PEP is not an appropriate place to make recommendations like this, especially without reaching out to the maintainer of attrs. As far as I know,the attrs and pydantic libraries are using the reference implementation, but their authors weren't consulted on the PEP itself.
Could you either change the wording (e.g. say that the unsupported features need bespoke type-checker functionality for proper type checking), or work with attrs to make the same recommendations in its documentation?
Happy typing, — Petr, on behalf of the Steering Council
Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/R4A2IYLG... Code of Conduct: http://python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.