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