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`?

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

> 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 <guido@python.org> 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 <carl@oddbird.net> wrote:

On Tue, Sep 21, 2021 at 9:05 PM Eric Traut <eric@traut.com> 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
_______________________________________________
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?)

_______________________________________________
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