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 <gohanpra@gmail.com> 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 <guido@python.org> 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 <eric@traut.com> 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)
_______________________________________________
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?)