To be clear, you propose that we write (int, P) -> str instead of (int, **P) -> str, with the same semantics (triggered by P being a ParamSpec), right? On Wed, Dec 22, 2021 at 9:15 AM Eric Traut wrote:

I'm fine with removing `async` from the spec. I think it's a reasonable simplification and eliminates some of the special-case parsing, as mentioned in the python-dev thread.

That same thread also mentions the `**` syntax for ParamSpecs. I'm OK eliminating this too. As someone mentioned, it requires special-case parsing, is not needed for correct semantic analysis, and (IMO) adds relatively little in the way of readability. I'm also OK leaving it in if others feel strongly about it and it doesn't become an obstacle for PEP 677 ratification.

-Eric _______________________________________________ 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: guido@python.org

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...

If true, how would you write a callable where ParamSpec is an actual parameter? On Wed, 2021-12-22 at 10:08 -0800, Guido van Rossum wrote:

To be clear, you propose that we write (int, P) -> str instead of (int, **P) -> str, with the same semantics (triggered by P being a ParamSpec), right?

On Wed, Dec 22, 2021 at 9:15 AM Eric Traut wrote:

...

I'm fine with removing `async` from the spec. I think it's a reasonable simplification and eliminates some of the special-case parsing, as mentioned in the python-dev thread.

That same thread also mentions the `**` syntax for ParamSpecs. I'm OK eliminating this too. As someone mentioned, it requires special- case parsing, is not needed for correct semantic analysis, and (IMO) adds relatively little in the way of readability. I'm also OK leaving it in if others feel strongly about it and it doesn't become an obstacle for PEP 677 ratification.

 -Eric _______________________________________________ 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: guido@python.org

_______________________________________________ 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: pbryan@anode.ca

I'd be okay with removing `**P` if we get that advice from many directions. But I'd much prefer to keep it: - **P is semantically very different from a normal variable, and the fact that it's a ParamSpec can live much higher up in the module. I think this can be a readability issue on unfamiliar code, even though it isn't on code that we're actively writing. - Given that we're introducing a similar *-for-unpack syntax in PEP 646, it seems inconsistent to me not to use a special syntax for ParamSpec So I'm not inclined to remove it just based on that one thread.

I had assumed ParamSpec was a type; Guido has corrected me on that. On Wed, 2021-12-22 at 18:24 +0000, Eric Traut wrote:

@Paul, could you clarify what you mean? An example would be helpful.

Do you want to pass a ParamSpec object as an argument to the callable, treating it like a runtime object rather than a special form? If so, then you'd annotate it as `(ParamSpec) -> None`. Is that what you mean?

 -Eric _______________________________________________ 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: pbryan@anode.ca

On Wed, Dec 22, 2021 at 18:48 Gregory P. Smith wrote:

On Wed, Dec 22, 2021 at 3:24 PM Nathaniel Smith wrote:

...

On Wed, Dec 22, 2021 at 7:13 AM Steven Troxler wrote:

...

Pradeep, Guido and I are leaning toward removing the `async` part of

PEP 677.

...

There are several reasons: - If we leave `async` in, then `async (int) -> bool` and `(int) ->

...

- This violates that there should only be one obvious way to do

Awaitable[bool]` are the same things

...

- It also might lead to a mismatch between written types and the errors returned by type checkers, leading to unnecessary confusion - It looks like < 5% of callable types return Awaitable anyway - It has explicitly been brought up in python-dev as unnecessary complexity, and we largely agree with this criticism.

For sync programs, it doesn't matter what we do, because they'll never write `async` or `Awaitable`. For async programs, having to put `Awaitable` everywhere adds a lot of visual noise. Most Python programs are sync, so any async-related syntax is necessarily going to be rare in absolute terms, but that's not really the relevant audience to think about.

For modern code, `Awaitable` isn't used at definition point: you just write `async def foo(a: int) -> bool`. So keeping it in PEP 677 would make definition syntax and callable type syntax more consistent. I think it's a big win for usability.

I also don't think it violates "one obvious way" -- emphasis on "obvious" :-). With PEP 677 as currently written, using `async` everywhere is the "obvious" way; `Awaitable` becomes a detail that only type nerds have to think about.

While I agree with the overall philosophy here, the async keyword in annotation context is a syntax addition that could be deferred until after PEP 677 to appear in a later version.

As a side note, Awaitable is available from the typing module where typing users are already importing a pile from, as well as collections.abc. But they appear to be different things. Eek. `typing.Awaitable` vs ``.

Really? They look closely related to me. What strikes you as different?

-gps

...

-n

-- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ 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: greg@krypto.org

_______________________________________________ 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: guido@python.org

-- --Guido (mobile)

(tl;dr: None of this is related to the thread's topic, and there's no need for alarm.) On Wed, Dec 22, 2021 at 9:06 PM Gregory P. Smith wrote:

As a side note, Awaitable is available from the typing module where typing

...

...

users are already importing a pile from, as well as collections.abc. But they appear to be different things. Eek. `typing.Awaitable` vs ``.

Really? They look closely related to me. What strikes you as different?

I just did a quick repr check. They're clearly not a reference to the same thing.

If I went and looked at the implementation I'm assuming they're ultimately the same thing for typing purposes? I just found it odd about the comment earlier about needing to import collections.abc for Awaitable. At first glance that doesn't appear necessary.

For historical reasons all things in typing that correspond to things in collections.abc (Mapping, Iterable, etc.) are all slightly different than the thing they try to resemble -- the versions in collections.abc were traditionally not generic (i.e. couldn't be subscripted), PEP 585 changed that (it has a full list of things affected) but for backwards compatibility they're not 100% equivalent at runtime. (Also, note the irregularity for [Abstract]Set in PEP 585.) Once you no longer need backwards compatibility with Python < 3.9, you *should* replace typing.XXX with collections.abc.XXX though, and fix whatever issues crop up -- I wouldn't know what would, but things that depend on typing internals might be affected. This is one reason we need to wait a long time before even deprecating these things. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...