Almost accepting PEP 681 – Data Class Transforms
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
El sáb, 23 abr 2022 a las 4:26, Petr Viktorin (
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.
Thanks Petr, that's great to hear! I opened a PR at https://github.com/python/cpython/pull/91861 so we can get the new decorator in before the feature freeze.
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?
Agree that these recommendations sound overly normative. I think we should remove the recommendations and simply spell out the features that won't work with dataclass_transform(). It's up to users' own judgment what they do with that information. Erik, could you propose a change to the PEP text?
Happy typing, — Petr, on behalf of the Steering Council _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com
* Erik, could you propose a change to the PEP text? I just created https://github.com/python/peps/pull/2555 to address these issues. -Erik
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
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.
+1. Glad it's not just me On 6/6/2022 2:36 PM, Victor Stinner wrote:
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 ;-)
I was also excited about the new built-in type :-) Pablo is already separating the PEPs in new release announcements (or has at least agreed to, not sure any releases have happened since I asked). But with the amount of work going on in separate venues these days, separating "CPython implementation" from "Language specification" from "Typing specification" would be helpful. (Packaging is already separate, but doesn't appear in release announcements anyway.) Cheers, Steve
or has at least agreed to, not sure any releases have happened since I asked). I did:
https://www.python.org/downloads/release/python-3110b3/#:~:text=3.11.0b3%20i...
.
On Mon, 6 Jun 2022 at 19:13, Steve Dower
+1. Glad it's not just me
On 6/6/2022 2:36 PM, Victor Stinner wrote:
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 ;-)
I was also excited about the new built-in type :-)
Pablo is already separating the PEPs in new release announcements (or has at least agreed to, not sure any releases have happened since I asked).
But with the amount of work going on in separate venues these days, separating "CPython implementation" from "Language specification" from "Typing specification" would be helpful. (Packaging is already separate, but doesn't appear in release announcements anyway.)
Cheers, Steve _______________________________________________ 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/3VJEOP2V... Code of Conduct: http://python.org/psf/codeofconduct/
On 06. 06. 22 20:05, Steve Dower wrote:
+1. Glad it's not just me
On 6/6/2022 2:36 PM, Victor Stinner wrote:
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 ;-)
I was also excited about the new built-in type :-)
Pablo is already separating the PEPs in new release announcements (or has at least agreed to, not sure any releases have happened since I asked).
But with the amount of work going on in separate venues these days, separating "CPython implementation" from "Language specification" from "Typing specification" would be helpful. (Packaging is already separate, but doesn't appear in release announcements anyway.)
There's an issue about adding the category metadata: https://github.com/python/peps/issues/2572 Rather than putting it in the title itself, it might be be better to only show the category more prominently in lists & announcements.
participants (6)
-
Erik De Bonte -
Jelle Zijlstra -
Pablo Galindo Salgado -
Petr Viktorin -
Steve Dower -
Victor Stinner