Mailing List Archive

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 <encukou@gmail.com> 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-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/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-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/LVNXFRLEMJXTEPC3N4M3NKQ4YRYQQZTA/
Code of Conduct: http://python.org/psf/codeofconduct/

+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/3VJEOP2VYQ66G4PS665QV52P5TGRYP5O/
Code of Conduct: http://python.org/psf/codeofconduct/

> 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 <steve.dower@python.org> 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-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/3VJEOP2VYQ66G4PS665QV52P5TGRYP5O/
> 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.

_______________________________________________
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/KY63VEYYMBETD2OKXHKI4BT7DRGPUOVE/
Code of Conduct: http://python.org/psf/codeofconduct/