Protocol classes should not match `Callable[..., Proto]`

[mikeshardmind (Michael H)]

@hauntsaninja

The requested behaviour would be similar to the behaviour here, whose specification dates back to PEP 544. Note this specified behaviour means we actually do mostly know a x is not Proto where x: type[Proto], so we don’t have transitivity issues.

I’m a bit concerned that this is going to catch other things that should be valid, but I guess we can deal with that if it comes up that type checkers are emitting false positives as a result of this.

@hauntsaninja

@mikeshardmind

I don’t think this is the right approach. We’ve seen more and more impacts of LSP exceptions

Ah interesting. I thought of my goal as complementary.

__init__ LSP violations are endemic.

Yeah, and that’s a problem in it of itself. It creates more problems than just telling people to use **_kwargs: object if they want to allow subclasses to add kwargs (and other such things). If we were able to limit all of the exceptions to those that are part of the data model or from object/type, and model the exceptions so that they only apply to overriding a default implementation, we could get actual soundness of type I’ve been working on language towards this route with `__hash__`, `__eq__`, and LSP

@hauntsaninja

If we can get to a point where --strict-type-instantiation is viable (that disallows instantiation of unknown non-final type[C] and assignment of unknown non-final type[C] to Callable[P, C])

I don’t see this as a goal worth pursuing, I think this is a configuration option that does more harm than good, much like those that flag Any/Unknown, they restrict valid code rather than gradually improve what is actually expressible and work towards making what exists possible to use soundly.