[Python-Dev] Re: Accepting PEP 681 – Data Class Transforms
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. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/KY63VEYYMBETD2OKXHKI4BT7DRGPUOVE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Accepting PEP 681 – Data Class Transforms
> 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%20is%20the%20second,support%20the%20new%20feature%20release . On Mon, 6 Jun 2022 at 19:13, 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.) > > Cheers, > Steve > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@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/3VJEOP2VYQ66G4PS665QV52P5TGRYP5O/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/R3Z4V7NZ2MOCUYDZZKNJLPZIGFA6Z2GN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Accepting PEP 681 – Data Class Transforms
+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-le...@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/3VJEOP2VYQ66G4PS665QV52P5TGRYP5O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Accepting PEP 681 – Data Class Transforms
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 wrote: > > 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-le...@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/R4A2IYLGFHKFDYJPSDA5NFJ6N7KRPJ6D/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/LVNXFRLEMJXTEPC3N4M3NKQ4YRYQQZTA/ Code of Conduct: http://python.org/psf/codeofconduct/