untyped defs on derived classes

[ostcar]

Currently all arguments and return values on untyped defs are set to Any.

It would be nice, if arguments and return values on derived classes would take the type annotations from the parent class. For example:

class A:
    def foo(self, a: str) -> None: pass


class B(A):
    def foo(self, a):
        reveal_type(a)

In this example the revealed type is Any but I would expect it to be str.

Of cause, if the entire project has type annotations, than this would not be an issue, but when you add type annotations on a big project and start with the base classes, it would be nice, if you could benefit from that.

[emmatyping]

I believe we probably don't want to support this unless --check-untyped-defs is enabled. Otherwise it would be inconsistent with how things work outside the class. If we restrict it to with that flag I believe this could be a nice feature to add, however this would complicate things and slow mypy.

[gvanrossum]

I think this should be a separate, new flag. Then it sounds worth considering.

[ilevkivskyi]

+1 from me for a separate flag.

[ilevkivskyi]

Also for reference, a very similar discussion happened in the typing tracker, see python/typing#269.

[JukkaL]

This can't be enabled by default, since a method override can have a different signature from the base class, and blindly inheriting the signature can generate false positives. A separate flag is worth considering, since similar things have been proposed several times.

[emmatyping]

Thinking more about it, I suppose an override should require a new type signature, as the method body is not inherited with an override, thus it is likely a signature not to be. So Im not sure I think this is such a good feature after all. If you are overriding, it is a different method body, thus inheriting the type signature seems wrong (at least to me).

However, if we do support this, I think a flag is too global, as these changes are likely to be only wanted on a single class or method even, but that is my personal experience on this.

[gvanrossum]

You could inherit the type signature (which I do think is the common case for method overrides) but still check the new body against that signature.

[JukkaL]

Yes, I think that this only makes sense if we check the body against the inherited signature. This is another reason why this needs to be opt-in -- unannotated methods are not type checked according to PEP 484.

[novoxd]

+1 this will be relay nice. Please add this for class variables too.

[OrDuan]

I want to point out that PyCharm added this to their code analyzer.
So far this is really helpful for me.
Usually I have a base class and child class that should have the same signatures, if it is different, I override it with different types.

[novoxd]

Whats real bad is that previous activity in this tread was about a ear ago, and nothing go on(