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