I'd be down for talking about this in the tensor typing meeting. As long as we'll have enough time - we also have someone from PyTorch presenting at the next meeting, right? On Tue, 31 Aug 2021 at 11:42, Alfonso L. Castaño wrote:

Hi Pradeep,

It definitely sounds like an interesting topic for discussion. However, why not using our existing monthly typing meeting for this purpose? Although in the name is included "Tensor", we mentioned time ago that we often don't have things to report every single month and we can include other topics.

Actually, the date that you are proposing overlaps with the next meeting, so it would kind of imply that we are cancelling that meeting.

Best, Alfonso. _______________________________________________ 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: mrahtz@google.com

No, I'd prefer to keep this a separate, dedicated meetup. Most people interested in callable syntax are unlikely to be interested in the specialized topic of Tensor shape types. I don't want either discussion to suffer just because we decided to merge the meetings. But thanks for bringing up the meeting conflict; I'll reschedule this. Revised date: September 20, 2021, 10 am San Francisco time. Agenda: + Overview of proposals + Stats + Pros and cons of different proposals + discussion Let me know if you are interested in presenting pros and cons for your favorite proposal. The document describes the five major proposals so far and how they behave in different scenarios [1]: + shorthand syntax: `(int, str) -> float` + hybrid syntax: `(int, str, c: bool=..., *args: int) -> float` + stub-style syntax: `(a: int, b: str, /, c: bool=..., *args: int) -> float` + shorthand xor stub-style syntax + a couple of other variations We could also invite a couple of interested people from python-dev so that we get early feedback on the viability of these syntax change proposals. [1]: Various proposals and use cases: https://docs.google.com/document/d/11VkNk9N8whxS1SrBv2BNN1Csl5yeTlgG7WyLrCB5... On Tue, Aug 31, 2021 at 3:44 AM Alfonso L. Castaño < alfonsoluis.castanom@um.es> wrote:

Yes that's right, we have someone presenting next week. However, how urgent is the Callable thing?

Depending on that there are several options: - Make the meeting longer. - Discuss it briefly during the remaining time. - Discuss it in the following meeting. - Schedule the following meeting in less than one month.

Best, Alfonso. _______________________________________________ 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: gohanpra@gmail.com

-- S Pradeep Kumar

Thanks for arranging this! That time works for me, and I'm interested in participating. I'm happy to present my thoughts on the pros/cons of various proposals. I personally think we should prioritize consistency and simplicity over flexibility and terseness. That is the lens I typically use when considering new language features. -Eric -- Eric Traut Contributor to Pyright & Pylance Microsoft Corp.

Hi all, The Callable Syntax meetup will be *Monday, 20th September at 10 am San Francisco time / 6 pm London time* at https://us02web.zoom.us/j/86376052915 . Agenda: + Brief overview + stats - Pradeep Kumar Srinivasan + Shorthand syntax - Steven Troxler + Stub-style syntax - Eric Traut + Hybrid syntax - Eric Traut All are welcome! There will be plenty of time for discussion. I'll share notes and recordings after the meeting. Thanks, On Wed, Sep 8, 2021 at 12:27 PM S Pradeep Kumar wrote:

Thanks for offering to present various proposals, Eric!

I'm aiming for us to discuss the top three proposals in this meetup: shorthand syntax, stub-style syntax, and hybrid syntax [1]. Steven wanted to present shorthand syntax. Eric could present the stub-style syntax and tentatively the hybrid syntax.

Last call for others: If you are interested in presenting the hybrid syntax proposal, please reply here. It'll be great to hear from different people. This will be a brief, informal presentation of pros and cons to start the discussion. If nobody signs up by the end of this week, the presenter will be Eric.

Agenda (for September 20th): + Greetings - 5m. + Brief overview + stats - Pradeep - 10m + 5m of discussion + Shorthand syntax - Steven - 10m + 5m of discussion + Stub-style syntax - Eric - 10m + 5m of discussion + Hybrid syntax - Eric (tentative) - 5m + 5m of discussion

I'll share the Zoom/Google Meet link next week.

[1]: Definition of various proposals and use cases: https://docs.google.com/document/d/11VkNk9N8whxS1SrBv2BNN1Csl5yeTlgG7WyLrCB5...

On Wed, Sep 1, 2021 at 9:28 AM Eric Traut wrote:

...

Thanks for arranging this! That time works for me, and I'm interested in participating.

I'm happy to present my thoughts on the pros/cons of various proposals. I personally think we should prioritize consistency and simplicity over flexibility and terseness. That is the lens I typically use when considering new language features.

-Eric

-- Eric Traut Contributor to Pyright & Pylance Microsoft Corp. _______________________________________________ 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: gohanpra@gmail.com

-- S Pradeep Kumar

-- S Pradeep Kumar

It's GMT+1. Here's a time converter link to be unambiguous: https://www.worldtimebuddy.com/?qm=1&lid=8,2643743,2643743&h=8&date=2021-9-20&sln=10-11&hf=1 On Fri, Sep 17, 2021 at 8:09 AM Sebastian Rittau wrote:

Am 17.09.21 um 01:00 schrieb S Pradeep Kumar:

The Callable Syntax meetup will be *Monday, 20th September at 10 am San Francisco time / 6 pm London time* at https://us02web.zoom.us/j/86376052915.

For clarification: Is London time currently at UTC or is there a dst offset?

- Sebastian

_______________________________________________ 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: gohanpra@gmail.com

-- S Pradeep Kumar

Reminder that the Callable Syntax meetup is today* at 10 am San Francisco time / 6 pm London time (GMT+1)* at https://us02web.zoom.us/j/86376052915. See you there! On Fri, Sep 17, 2021 at 11:48 AM Guido van Rossum wrote:

I just ask Google or Bing "what time is it in London" :-)

On Fri, Sep 17, 2021 at 11:18 AM S Pradeep Kumar wrote:

...

It's GMT+1. Here's a time converter link to be unambiguous: https://www.worldtimebuddy.com/?qm=1&lid=8,2643743,2643743&h=8&date=2021-9-20&sln=10-11&hf=1

On Fri, Sep 17, 2021 at 8:09 AM Sebastian Rittau wrote:

...

Am 17.09.21 um 01:00 schrieb S Pradeep Kumar:

The Callable Syntax meetup will be *Monday, 20th September at 10 am San Francisco time / 6 pm London time* at https://us02web.zoom.us/j/86376052915.

For clarification: Is London time currently at UTC or is there a dst offset?

- Sebastian

_______________________________________________ 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: gohanpra@gmail.com

-- S Pradeep Kumar _______________________________________________ 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...

-- S Pradeep Kumar

On Mon, Sep 20, 2021 at 8:35 PM S Pradeep Kumar wrote:

Thanks everyone for the discussions in the meetup.

Thanks for organizing! 1. Slides:

Pradeep - Callable syntax stats - https://drive.google.com/file/d/1k_TqrNKcbWihRZdhMGf6K_GcLmn9ny3m/view?usp=s... Steven - Callable examples and questions - https://drive.google.com/file/d/119gt9-nCa_mGUjAVanWT2mscC3KlhfN4/view?usp=s... Eric - TBD (could you share them?). Doc containing proposal details: https://docs.google.com/document/d/11VkNk9N8whxS1SrBv2BNN1Csl5yeTlgG7WyLrCB5...

2. Meeting notes:

+ Nobody was in favor of the def-style syntax by itself, since it was verbose for the most common cases. The need for forward-slash to indicate positional-only parameters was another confusing pitfall.

+ Jake Bailey pointed out that, if lambdas get special syntax, Callable types would need to be distinguishable from them. Steven suggested that having different arrow styles could help: something like `(int) -> str` for callable types and `(x, y) => x + y` for lambdas.

+ Jelle Zijlstra asked if the rejection of PEP 637 (Support for indexing with keyword arguments) by the Steering Council could bode poorly for callable syntax. Guido mentioned that the rejection there was more about keyword arguments in indexing. Typing syntax was only a peripheral concern in that PEP.

3. Straw poll at the end of the meetup:

Hybrid style: 8 votes - Nikita, James Hilton-Balfe, nadirchowdhury, Martin, Sebastian, Guido, Carl, Jake.

Shorthand style: 6 votes - Rebecca, Shannon, Jia, Steven, Eric, Pradeep.

4. Rationale for hybrid over shorthand: I'm interested in hearing about the use cases that people care about here. If you favor hybrid over shorthand, could you share your reasons why? We can try to find a solution that addresses those use cases while being well-specified.

For me, if we're getting an improved callable syntax, it would be really sad if it couldn't express all callable types that are in the language. In particular, defaults and keyword arguments (and *args/**kwds) are such an important part of the language that they really should be supported. We declined to do this with the original Callable syntax only because we just couldn't come up with an acceptable way to spell those at all given the constraints of "no new syntax" at the time. It's also been an eye-opener that Callable is the most popular type form after Union. And no, I don't count overloads for this purpose. They are ugly enough in definitions, and as a separately expressed *type* they just aren't used (I betcha you didn't find any in your survey). This is where the Protocol notation will be useful -- overloads are essentially a multi-line notation, unlike all other type notations (which are expression-like), but like Protocols.

5. Follow-up: Are you interested in a general typing meetup every month or two?

People could present ideas or PEPs they're working on and get quick, early feedback. Discussions could generally move along faster in person if there's some deadlock in typing-sig. (This would be for typing-sig topics in general, not just callable syntax.)

That would be great. We used to have in-person meetings for typing people in the Bay Area a few times a year, and once a year at PyCon, but for this purpose I like remote meetings better -- much more accessible (despite time zones). -- --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...

Thanks Pradeep for organizing and leading the meeting! On Mon, Sep 20, 2021 at 9:35 PM S Pradeep Kumar wrote:

+ Nobody was in favor of the def-style syntax by itself, since it was verbose for the most common cases. The need for forward-slash to indicate positional-only parameters was another confusing pitfall.

The straw poll went by quite quickly at the end of the call, but if I'm not mistaken Eric Traut voted for def-style syntax as top preferred option? I'm curious if Eric wants to say more about that preference before the option is discarded (unless I saw the vote wrong.) I see the attractiveness of reducing the number of ways to express a signature that exist in the language, but ISTM that with def syntax we end up with the most common cases of callable annotations almost as verbose (and arguably more error-prone) than the current Callable syntax. This seems unfortunate since making the common cases easier to type correctly (so fewer people give up and just go with plain `Callable`) was (as far as I know) a primary motivation for a new syntax.

3. Straw poll at the end of the meetup:

Hybrid style: 8 votes - Nikita, James Hilton-Balfe, nadirchowdhury, Martin, Sebastian, Guido, Carl, Jake.

Shorthand style: 6 votes - Rebecca, Shannon, Jia, Steven, Eric, Pradeep.

It looks like the group of people favoring shorthand are all people actively maintaining a type checker that will have to implement support for the chosen syntax ;)

4. Rationale for hybrid over shorthand: I'm interested in hearing about the use cases that people care about here. If you favor hybrid over shorthand, could you share your reasons why? We can try to find a solution that addresses those use cases while being well-specified.

Personally I'd be fine with starting with shorthand, since there are still callable protocols as a fallback, and consider extending its syntax based on more experience. With ParamSpec, TypeVarTuple, and a (still hypothetical) future TypedKwargsDict, it seems like shorthand can already express something like 80-90% of the uses. Probably the highest-priority addition to shorthand syntax would be support for default-value params.

5. Follow-up: Are you interested in a general typing meetup every month or two?

Yes, I would attend. Carl

On Tue, Sep 21, 2021 at 9:05 PM Eric Traut wrote:

...

if I'm not mistaken Eric Traut voted for def-style syntax as top preferred option

Actually, I voted for the shorthand option. The data that Pradeep presented convinced me that def-style syntax is too verbose for the common cases. The hybrid option is my least favorite. I really hope we don't end up with that option. It brings all of the disadvantages of the shorthand option (a syntax that is similar to the def statement but different in some ways that could be confusing to users) plus it adds a bunch of redundancy, further inconsistency, and complexity to handle rare use cases that can already be handled through callback protocols.

I was mistaken! Thanks for clarifying, Carl

Thanks everyone for the inputs. 1. Use cases beyond shorthand:

Guido: For me, if we're getting an improved callable syntax, it would be really sad if it couldn't express all callable types that are in the language. In particular, defaults and keyword arguments (and *args/**kwds) are such an important part of the language that they really should be supported. We declined to do this with the original Callable syntax only because we just couldn't come up with an acceptable way to spell those at all given the constraints of "no new syntax" at the time. It's also been an eye-opener that Callable is the most popular type form after Union.

Carl: Probably the highest-priority addition to shorthand syntax would be support for default-value params.

Guido: That would be great. We used to have in-person meetings for typing

Sebastian: I also think that having a regular meeting would be beneficial. We have quite a few people and parties working on various aspects of typing by now, and discussion is often spread over a few mailing

It looks like there is some interest in supporting default-value parameters, *args, etc. The aim here seems to be more about having a way to express these types in the new syntax than about using the specific "hybrid" syntax. 2. As Carl noticed, typechecker folks are hesitant about the "hybrid" syntax as such, because it will add more confusion and complexity. It looks kind of similar to def-style but isn't. We would have to come up with new rules for how to specify different parts of the signature, which will make it harder for users to learn: (a) should it be **int or **kwargs: int? (b) is `(int, str=...) -> bool` valid or do we have to use (int, x: str=...) -> bool? (c) should we allow `(int, x: str, bool) -> str`? The added complexity in the particular "hybrid" approach doesn't seem worth the infrequent usage. --------- 3. Can we consider a cleaner compromise? I call this the XOR proposal (or the "have our cake and eat it too" proposal): ``` callable_syntax := | shorthand_syntax | def_style_syntax ``` That is, users can use either the shorthand syntax or the def-style syntax, but not a random mix (unlike hybrid). Pros: 1. That way, the vast majority of cases would just be in shorthand: `(int, str) -> bool`, etc. It still has the advantage over pure, verbose def-style. 2. In the rare cases where people really want to use default values, *args, etc. they can use the explicit def-style syntax: `(x: int, y: str, z: int=..., *args: bool) -> int`. 3. Each syntax is clearly-specified. Shorthand syntax is simple and hard to screw up. Def-style syntax, while complex, is highly familiar. There is no ambiguity about how to specify **kwargs: int or default values ("There should be one -- and preferably only one -- obvious way to do it."). So, we don't have to spend much time inventing, implementing, or teaching rules for the new syntax. 4. All features from function signatures will be available as is: default values, keyword-only, *args, etc. (except overloads). Users can just copy-paste complex signatures from the functions, if needed. 5. Forward-slash won't be as much of an issue since the users who use def-style syntax probably do want the parameter names to be significant. Ordinary users won't need to learn about forward-slash for positional-only parameters since they'll just use shorthand. Cons: 1. There will be two ways to specify positional-only parameters. But we already have callback protocols, so it shouldn't be a huge deal given that this is a compromise. There will be only one obvious way to write positional parameters: shorthand syntax. 2. Teaching difficulty: Could be confusing to hear about multiple options. We could just teach new users about shorthand and leave the def-style syntax as an advanced option that is there if they need it. 3. People can't easily add just one named parameter to shorthand syntax. They will have to name all the parameters. This use case will be rare, so it should be an acceptable cost. What do you think? --------- Section 4. Overall, shorthand syntax is forward-compatible. As Carl suggested, we could land shorthand syntax first. We could follow it up later with either: (a) def-style syntax (b) Lukasz's proposal of function name as type (c) or just stick with callback protocols for the advanced cases. This way, our experience with the new syntax would guide the option taken. As Eric pointed out: Adding new capabilities to a language is relatively easy; removing them is almost impossible. Does this staged approach sound reasonable? 5. Typing meetups people in the Bay Area a few times a year, and once a year at PyCon, but for this purpose I like remote meetings better -- much more accessible (despite time zones). lists (typing-sig, python-dev), the Python bug tracker, and various GitHub repositories, in addition to private chats. Channeling the more important or controversial discussions from time to time could help with that.

Carl: Yes, I would attend.

Great! I'll announce a meeting for a month from now in a separate thread. PS:

Guido: And no, I don't count overloads for this purpose. They are ugly enough in definitions, and as a separately expressed *type* they just aren't used (I betcha you didn't find any in your survey).

I'd seen exactly *one* use of this, but your point stands :) ( https://github.com/python/typeshed/blob/master/stdlib/smtplib.pyi#L50) On Thu, Sep 23, 2021 at 9:02 AM Guido van Rossum wrote:

Personally I think Eric is too pessimistic. Once you've seen ``` callback: (str, str) -> list[str] ``` this looks like a quite natural extension: ``` callback: (str, str, spam: bool = False) -> list[str] ``` The rule is more or less "the syntax is similar to a `def` parameter list, but if there's no colon, the thing that's there is the type, not the parameter name.

On Thu, Sep 23, 2021 at 8:26 AM Carl Meyer wrote:

...

...

...

if I'm not mistaken Eric Traut voted for def-style syntax as top

On Tue, Sep 21, 2021 at 9:05 PM Eric Traut wrote: preferred option

...

Actually, I voted for the shorthand option. The data that Pradeep

presented convinced me that def-style syntax is too verbose for the common cases. The hybrid option is my least favorite. I really hope we don't end up with that option. It brings all of the disadvantages of the shorthand option (a syntax that is similar to the def statement but different in some ways that could be confusing to users) plus it adds a bunch of redundancy, further inconsistency, and complexity to handle rare use cases that can already be handled through callback protocols.

I was mistaken! Thanks for clarifying,

Carl _______________________________________________ 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... _______________________________________________ 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: gohanpra@gmail.com

-- S Pradeep Kumar

I'm curious about the semantics of default values in a callable type. For example, would def f(x: int = 42) -> None: ... be a subtype of (x: int = 24) -> None or (x: int = ...) -> None ? On Tue, Sep 28, 2021 at 12:27 AM Guido van Rossum wrote:

My preferred variant of hybrid syntax uses this for the form of a parameter:

[NAME ':'] type ['=' default]

where both `type` and `default` are syntactically expressions. The new PEG parser has no trouble with this.

There would be several additional rules:

- if a parameter specifies the `NAME '='` part, all following parameters must too - a '/' is inserted before the first parameter that has the `NAME '='` part - a '*' or '**' prefix is allowed, using all the usual constraints

On Sat, Sep 25, 2021 at 10:44 PM S Pradeep Kumar wrote:

...

Thanks everyone for the inputs.

1. Use cases beyond shorthand:

...

Guido: For me, if we're getting an improved callable syntax, it would be really sad if it couldn't express all callable types that are in the language. In particular, defaults and keyword arguments (and *args/**kwds) are such an important part of the language that they really should be supported. We declined to do this with the original Callable syntax only because we just couldn't come up with an acceptable way to spell those at all given the constraints of "no new syntax" at the time. It's also been an eye-opener that Callable is the most popular type form after Union.

...

Carl: Probably the highest-priority addition to shorthand syntax would be support for default-value params.

It looks like there is some interest in supporting default-value parameters, *args, etc. The aim here seems to be more about having a way to express these types in the new syntax than about using the specific "hybrid" syntax.

2. As Carl noticed, typechecker folks are hesitant about the "hybrid" syntax as such, because it will add more confusion and complexity. It looks kind of similar to def-style but isn't. We would have to come up with new rules for how to specify different parts of the signature, which will make it harder for users to learn:

(a) should it be **int or **kwargs: int? (b) is `(int, str=...) -> bool` valid or do we have to use (int, x: str=...) -> bool? (c) should we allow `(int, x: str, bool) -> str`?

In my version, (a) both, (b) both, (c) no.

...

The added complexity in the particular "hybrid" approach doesn't seem worth the infrequent usage.

---------

3. Can we consider a cleaner compromise? I call this the XOR proposal (or the "have our cake and eat it too" proposal):

``` callable_syntax := | shorthand_syntax | def_style_syntax ```

That is, users can use either the shorthand syntax or the def-style syntax, but not a random mix (unlike hybrid).

I don't think anyone has specified hybrid sufficiently formally to know whether it supports a "random" mix.

Similarly, is `(foo, bar) -> int` shorthand or def-style syntax? If we prepend `def f`, it is valid.

...

Pros:

1. That way, the vast majority of cases would just be in shorthand: `(int, str) -> bool`, etc. It still has the advantage over pure, verbose def-style. 2. In the rare cases where people really want to use default values, *args, etc. they can use the explicit def-style syntax: `(x: int, y: str, z: int=..., *args: bool) -> int`. 3. Each syntax is clearly-specified. Shorthand syntax is simple and hard to screw up. Def-style syntax, while complex, is highly familiar. There is no ambiguity about how to specify **kwargs: int or default values ("There should be one -- and preferably only one -- obvious way to do it."). So, we don't have to spend much time inventing, implementing, or teaching rules for the new syntax. 4. All features from function signatures will be available as is: default values, keyword-only, *args, etc. (except overloads). Users can just copy-paste complex signatures from the functions, if needed. 5. Forward-slash won't be as much of an issue since the users who use def-style syntax probably do want the parameter names to be significant. Ordinary users won't need to learn about forward-slash for positional-only parameters since they'll just use shorthand.

Cons:

1. There will be two ways to specify positional-only parameters. But we already have callback protocols, so it shouldn't be a huge deal given that this is a compromise. There will be only one obvious way to write positional parameters: shorthand syntax. 2. Teaching difficulty: Could be confusing to hear about multiple options. We could just teach new users about shorthand and leave the def-style syntax as an advanced option that is there if they need it. 3. People can't easily add just one named parameter to shorthand syntax. They will have to name all the parameters. This use case will be rare, so it should be an acceptable cost.

What do you think?

I want a solution that can capture all types you can specify using `def` (excepting `@overload`).

...

---------

Section 4. Overall, shorthand syntax is forward-compatible. As Carl suggested, we could land shorthand syntax first. We could follow it up later with either:

(a) def-style syntax (b) Lukasz's proposal of function name as type (c) or just stick with callback protocols for the advanced cases.

This way, our experience with the new syntax would guide the option taken. As Eric pointed out: Adding new capabilities to a language is relatively easy; removing them is almost impossible.

Does this staged approach sound reasonable?

5. Typing meetups

...

Guido: That would be great. We used to have in-person meetings for typing people in the Bay Area a few times a year, and once a year at PyCon, but for this purpose I like remote meetings better -- much more accessible (despite time zones). Sebastian: I also think that having a regular meeting would be beneficial. We have quite a few people and parties working on various aspects of typing by now, and discussion is often spread over a few mailing lists (typing-sig, python-dev), the Python bug tracker, and various GitHub repositories, in addition to private chats. Channeling the more important or controversial discussions from time to time could help with that. Carl: Yes, I would attend.

Great! I'll announce a meeting for a month from now in a separate thread.

PS:

...

Guido: And no, I don't count overloads for this purpose. They are ugly enough in definitions, and as a separately expressed *type* they just aren't used (I betcha you didn't find any in your survey).

I'd seen exactly *one* use of this, but your point stands :) ( https://github.com/python/typeshed/blob/master/stdlib/smtplib.pyi#L50)

On Thu, Sep 23, 2021 at 9:02 AM Guido van Rossum wrote:

...

Personally I think Eric is too pessimistic. Once you've seen ``` callback: (str, str) -> list[str] ``` this looks like a quite natural extension: ``` callback: (str, str, spam: bool = False) -> list[str] ``` The rule is more or less "the syntax is similar to a `def` parameter list, but if there's no colon, the thing that's there is the type, not the parameter name.

On Thu, Sep 23, 2021 at 8:26 AM Carl Meyer wrote:

...

...

...

if I'm not mistaken Eric Traut voted for def-style syntax as top

On Tue, Sep 21, 2021 at 9:05 PM Eric Traut wrote: preferred option

...

Actually, I voted for the shorthand option. The data that Pradeep

presented convinced me that def-style syntax is too verbose for the common cases. The hybrid option is my least favorite. I really hope we don't end up with that option. It brings all of the disadvantages of the shorthand option (a syntax that is similar to the def statement but different in some ways that could be confusing to users) plus it adds a bunch of redundancy, further inconsistency, and complexity to handle rare use cases that can already be handled through callback protocols.

I was mistaken! Thanks for clarifying,

Carl _______________________________________________ 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... _______________________________________________ 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: gohanpra@gmail.com

-- S Pradeep Kumar

-- --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... _______________________________________________ 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: sergei.a.lebedev@gmail.com

I was guessing that would be the case. Do you think we should encode this in the syntax and restrict the default expression to ...? On Tue, Sep 28, 2021 at 4:16 PM Eric Traut wrote:

...

I'm curious about the semantics of default values in a callable type

The value of a default doesn't affect the type of the callable, but the presence of a default does.

From a type perspective:

`(x: int = 42) -> None` is equivalent to both `(x: int = 0) -> None` and `(x: int = ...) -> None`.

and

`(x: int = ...) -> None` is compatible with both `(x: int) -> None` and `() -> None`.

-Eric

-- Eric Traut Contributor to pyright & pylance Microsoft Corp. _______________________________________________ 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: sergei.a.lebedev@gmail.com

That seems undesirable. A programmer who has a value annotated with static type (x: int = 0) -> None who wants to pass 0 might assume it's safe to call it without the argument. But if that value might be a function of type (x: int = 42) -> None then that program should not type check. On Tue, 28 Sept 2021, 16:16 Eric Traut, wrote:

...

I'm curious about the semantics of default values in a callable type

The value of a default doesn't affect the type of the callable, but the presence of a default does.

From a type perspective:

`(x: int = 42) -> None` is equivalent to both `(x: int = 0) -> None` and `(x: int = ...) -> None`.

and

`(x: int = ...) -> None` is compatible with both `(x: int) -> None` and `() -> None`.

-Eric

-- Eric Traut Contributor to pyright & pylance Microsoft Corp. _______________________________________________ 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: kmillikin@google.com

The thing I am worried about is the sudden change in readability when just one parameter doesn't fit the "simple" pattern. I think of this as a "cliff" or "discontinuity" in usability, and I don't like those unless absolutely necessary. This is related to "similar things should look similar, and different things should look different". E.g. if we have a function f(x, y) with a type (int, int) -> int, and we add a single optional argument, say f(x, y, z=0), we'd have to rewrite the type as (x: int, y: int, z: int = 0, /) -> int (note the trailing /), whereas in the hybrid variant I am championing this could be expressed by simply adding ", int=0" to the initial signature. IMO adding that one optional parameter (probably optional for backwards compatibility, or perhaps because planar coordinates are an important use case to the application) doesn't make the signature different enough to warrant such a discontinuity in how it is spelled in the XOR proposal. On Fri, Oct 1, 2021 at 11:48 AM S Pradeep Kumar wrote:

...

3. Can we consider a cleaner compromise? I call this the XOR proposal (or the "have our cake and eat it too" proposal):

``` callable_syntax := | shorthand_syntax | def_style_syntax ```

...

I want a solution that can capture all types you can specify using `def` (excepting `@overload`).

Guido: Yes, the xor syntax was designed to do exactly that. Did you have thoughts on using the xor syntax instead of the hybrid syntax?

Given how rarely the additional features will be used, it seems better to have a straightforward def-style way to specify them instead of having several additional rules for allowing (x: str=...) -> int, (str=...) -> int, (**int) -> int, etc.

Overall, shorthand is compatible with both xor and hybrid, so adding the additional syntax later should be relatively easy if needed. I'd prefer just shorthand over either hybrid or xor.

Likewise, xor syntax is compatible with the hybrid syntax (the latter accepts any instance of the former). So, if we discover that we do want the extra features from hybrid, we could easily add them in the future. So, if just shorthand is not acceptable, I'd prefer xor over hybrid. Going for hybrid right away seems like we are prematurely adding complexity for rare cases.

...

There would be several additional rules:

- if a parameter specifies the `NAME '='` part, all following parameters must too - a '/' is inserted before the first parameter that has the `NAME '='` part - a '*' or '**' prefix is allowed, using all the usual constraints

...

(a) should it be **int or **kwargs: int? (b) is `(int, str=...) -> bool` valid or do we have to use (int, x: str=...) -> bool? (c) should we allow `(int, x: str, bool) -> str`?

In my version, (a) both, (b) both, (c) no.

Thanks for specifying hybrid some more.

...

Similarly, is `(foo, bar) -> int` shorthand or def-style syntax? If we prepend `def f`, it is valid.

Good point. We would restrict `def_style_syntax` to fully-typed signatures. So, `(foo, bar) -> int` would be parsed as the shorthand syntax.

On Tue, Sep 28, 2021 at 10:47 AM Kevin Millikin via Typing-sig < typing-sig@python.org> wrote:

...

That seems undesirable. A programmer who has a value annotated with static type (x: int = 0) -> None who wants to pass 0 might assume it's safe to call it without the argument. But if that value might be a function of type (x: int = 42) -> None then that program should not type check.

On Tue, 28 Sept 2021, 16:16 Eric Traut, wrote:

...

...

I'm curious about the semantics of default values in a callable type

The value of a default doesn't affect the type of the callable, but the presence of a default does.

From a type perspective:

`(x: int = 42) -> None` is equivalent to both `(x: int = 0) -> None` and `(x: int = ...) -> None`.

and

`(x: int = ...) -> None` is compatible with both `(x: int) -> None` and `() -> None`.

-Eric

-- Eric Traut Contributor to pyright & pylance Microsoft Corp. _______________________________________________ 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: kmillikin@google.com

_______________________________________________ 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: gohanpra@gmail.com

-- S Pradeep Kumar _______________________________________________ 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...

I guess we have to agree to disagree at this point. For me personally, callback protocols are a cliff too steep: You don't just have to switch to a more verbose syntax for each parameters (like the def_style variant in the XOR proposal), but you have to switch to statement-level syntax (as opposed to inline expression syntax) *and* you are required to *name* the protocol class as well (which oddly has usability issues in some cases, since the reader may need an additional hint to know whether this protocol class is used in one place only or in multiple). So that's really three separate cliffs. For overloads, which themselves are pretty clumsy statement-level syntax, the switch to statement-level syntax is more acceptable; but I find it prohibitive to just add a keyword or optional parameter -- *even* if that's only a small fraction of use cases. On Mon, Oct 4, 2021 at 11:23 AM Eric Traut wrote:

I think we have broad agreement that it's reasonable to have a "cliff" in the case of overloaded signatures. If overloads are needed, a callback protocol can be used.

If we're willing to accept that there's going to be a "cliff" at some point, shouldn't we use data to inform where that cliff is?

Pradeep did some great analysis that shows how `Callable` and callback protocols are used today in stubs and in typed Python code bases . Based on his analysis, it seems reasonable to support only the shorthand proposal and direct users to a callback protocol in the rare case where they need something more sophisticated. Otherwise we will be taking on all of the complexity (and redundancy) to accommodate this rarely-used functionality.

Can we please just stick to the shorthand proposal for now? This doesn't preclude us from adding more complexity in the future if it proves to be useful. I haven't heard a good justification for why we want to rush to add this additional complexity and redundancy for cases that are rarely going to arise, especially when we have a good fallback solution (callback protocols) that covers those cases.

-Eric

-- Eric Traut Contributor to pyright & pylance Microsoft _______________________________________________ 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...

I recommend that you try this out on python-dev. It could degenerate into bikeshedding a minor detail, or it could erupt in a flamewar, or you could receive deafening silence. Or you could get useful feedback. But on typing-sig I think we've exhausted our arguments. On Mon, Oct 4, 2021 at 4:14 PM S Pradeep Kumar wrote:

...

I guess we have to agree to disagree at this point.

I find it prohibitive to just add a keyword or optional parameter -- *even* if that's only a small fraction of use cases.

Guido, it looks like you feel strongly about having syntax beyond just shorthand in the initial proposal itself. If we are at a point where we agree to disagree, I think we can talk about next actions.

I see two options:

+ Option 1: We could have two competing PEPs - one for shorthand-only and one for hybrid.

This option makes it clear there's no strong consensus in typing-sig. Each one could make the best case for itself and list out pros and cons. The shorthand-only PEP would leave room for new syntax in the future based on experience, whether it is hybrid or xor or something else.

We could ask for opinions from the Steering Council and python-dev, since that's a large remaining source of uncertainty.

But if you're strongly against sponsoring the shorthand-only PEP, then I'm guessing this will be a non-starter :)

+ Option 2: We could put up a two-part PEP containing shorthand syntax plus the additional features provided by hybrid syntax.

If the Steering Council feels the complexity of the extra hybrid syntax is not yet justified by the additional impact, we could offer to fall back to just shorthand syntax for now. Otherwise, if they are ok with both, then we just go ahead with hybrid syntax, regardless of any misgivings in typing-sig.

What do you suggest? Any other options? (Opinions from others?)

On Mon, Oct 4, 2021 at 11:53 AM Guido van Rossum wrote:

...

I guess we have to agree to disagree at this point.

For me personally, callback protocols are a cliff too steep: You don't just have to switch to a more verbose syntax for each parameters (like the def_style variant in the XOR proposal), but you have to switch to statement-level syntax (as opposed to inline expression syntax) *and* you are required to *name* the protocol class as well (which oddly has usability issues in some cases, since the reader may need an additional hint to know whether this protocol class is used in one place only or in multiple).

So that's really three separate cliffs.

For overloads, which themselves are pretty clumsy statement-level syntax, the switch to statement-level syntax is more acceptable; but I find it prohibitive to just add a keyword or optional parameter -- *even* if that's only a small fraction of use cases.

On Mon, Oct 4, 2021 at 11:23 AM Eric Traut wrote:

...

I think we have broad agreement that it's reasonable to have a "cliff" in the case of overloaded signatures. If overloads are needed, a callback protocol can be used.

If we're willing to accept that there's going to be a "cliff" at some point, shouldn't we use data to inform where that cliff is?

Pradeep did some great analysis that shows how `Callable` and callback protocols are used today in stubs and in typed Python code bases . Based on his analysis, it seems reasonable to support only the shorthand proposal and direct users to a callback protocol in the rare case where they need something more sophisticated. Otherwise we will be taking on all of the complexity (and redundancy) to accommodate this rarely-used functionality.

Can we please just stick to the shorthand proposal for now? This doesn't preclude us from adding more complexity in the future if it proves to be useful. I haven't heard a good justification for why we want to rush to add this additional complexity and redundancy for cases that are rarely going to arise, especially when we have a good fallback solution (callback protocols) that covers those cases.

-Eric

-- Eric Traut Contributor to pyright & pylance Microsoft _______________________________________________ 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... _______________________________________________ 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: gohanpra@gmail.com

-- S Pradeep Kumar

-- --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...