Creating type stubs for a library is a tall ask for 99% of pylance’s 12M+ users. I don’t think that’s an acceptable answer.
There is precedent for this. Type checkers treat unannotated class and function decorators as having no effect on the decorated function. That makes sense because it’s a reasonable (and correct) assumption the vast majority of the time. Treating unannotated decorators as though they return Any and asking users to “write your own stubs if you want this to work” would be a big step backward in terms of usability. I see the metaclass __call__ case as similar. If a library author is going to do something extremely nonstandard, let’s put the onus on them to provide a non-Any return type annotation.
I feel like my ideal behavior (for both __call__ and __new__) would look something like:
no return type annotation: assume an instance of the class is returned
if annotated to return anything other than an instance of the class (including Any): something special is being done, don’t evaluate subsequent constructor methods
I agree with Eric’s point that this isn’t the time to try to introduce a full-blown Unknown type, but what about specifically special-casing constructor methods to have an assumed return type annotation when they’re left unannotated?
I’ve updated the proposed spec to incorporate @rchen152’s suggestion. Please review and add comments if you think it’s unclear or I missed any important points.