Draft typing spec chapter for constructors

[mikeshardmind (Michael H)]

Perspective on why some of the current behavior and user types are the way they are might help here.
Please don’t read the below as “we need to enforce LSP on __init__ / __new__”, that’s a way forward, but it’s not the only one, and as prior discussions got into, there’s reasons why this wasn’t done.

@tmk

Re: “Constructor Calls for type[T]”, I’ve come to realize that when people use type[T], what they usually actually want is Callable[[...], T] (where ideally the argument types are specified explicitly). The latter is actually type-safe (no subclassing problem), more flexible (you can also pass in functions in addition to classes), and generally more robust and explicit.

The only situation I can think of where you genuinely need type[T] is when you want to call static or class methods on the class object. But you’d probably be better off with defining a Protocol for that case:

1. This is only the case due to type checkers not enforcing LSP for __init__ and might indicate that prior proposals to copy a signature for sure elsewhere paired with intersections would help here (ie. T & Callable[T.__init__, T]) This would ensure that a type could be constructed as expected.

2. While it might be better to define a complex protocol for some of those cases, I don’t see many people being willing to do it when type[T] appears to work until someone makes a subclass that violates LSP on __init__

@erictraut

@Jelle

One thing I was surprised by: Your draft states that if __new__ returns Any, then the return type should be ignored

I’m not very convicted on this point. However, I think it’s important that if the __new__ method is unannotated and its return type is inferred as Any (or Unknown, using pyright’s terminology), then a type checker should assume a return type of Self. If a __new__ is explicitly annotated to return Any, then I think there’s a reasonable argument that the constructor call should evaluate to Any. I’m not sure what that means for the __init__ evaluation though. Should a type checker assume that the __init__ method is not called in this case? Or that it is called? The former will mask errors (false negatives), and the latter could potentially lead to false positives.

I don’t think it’s a good idea to have a situation where Annotating with the inferred type without an annotation (Any) changes the behavior. This feels like it also is partially necessary due to how __init__ and __new__ are not required to be LSP compatible.

There might be a better inferrable type than Any using the method that was mentioned in the discussion of subtyping involving Any, but this isn’t something that would be user-denotable currently or for a while.

@erictraut

The reason that pyright looks at __init__ methods first when converting to a callable is that __init__ method is typically richer in type information. __new__ method signatures often consist of (cls, *args, **kwargs) which is not very useful from a typing perspective. It appears that mypy does the same — presumably for the same reason.

The ability to partially copy signatures might lead to more people typing __new__accurately, speaking for only myself, the inability to do so is the primary reason I don’t give new more detailed typing. The secondary reason is that type checkers largely ignore it anyway.