You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
@final decorator is not honored on override with --check-untyped-defs #9618
Overriding class methods marked with @final(pep-0591) are not reported as errors. The example script will not produce an error with mypy even though it probably should.
#9612 is potentially related, but they have a final problem in the other direction.
Hi, just wanted to note that when I tried this example, mypy gives the expected error about final as soon as any annotation is added to Derived's foo method. It's possible that the design was intentionally not to check final for untyped functions? Either way, the workaround is easy.
(There is the --check-untyped-defs option but that does not work to produce the error, which I guess makes sense since the docs say it enables checking the body of a function).
@tfranzel Did you look at the mypy-playground example I linked to? Here's the content:
from typing import final
class Base:
@final
def foo(self):
pass
def bar(self):
pass
class Derived(Base):
def foo(self) -> None:
pass
It's the same as your OP but with a return annotation " -> None" added to Derived.foo. When I said this is fixed by adding an annotation I meant in the usual PEP 484 sense of type annotations, not decorators.
ahh sorry i somehow missed the link. i see, so the functionality is there. nonetheless kind of weird to only activate the check once a type hint is present.
I suppose this is because of mypy's general principle to not give errors for unannotated code. It feels like we should give the error if --check-untyped-defs is on, though.
changed the title [-]`@final` decorator is not honored. no error on override.[/-][+]`@final` decorator is not honored on override with --check-untyped-defs[/+]on Aug 13, 2023
Activity
a-reich commentedon Oct 27, 2020
Hi, just wanted to note that when I tried this example, mypy gives the expected error about
finalas soon as any annotation is added toDerived'sfoomethod. It's possible that the design was intentionally not to checkfinalfor untyped functions? Either way, the workaround is easy.(There is the
--check-untyped-defsoption but that does not work to produce the error, which I guess makes sense since the docs say it enables checking the body of a function).tfranzel commentedon Nov 1, 2020
hey @a-reich, i cannot reproduce your statement. adding some other decorator didn't change the outcome.
also using
@finalagain with derived did nothing:a-reich commentedon Nov 1, 2020
@tfranzel Did you look at the mypy-playground example I linked to? Here's the content:
It's the same as your OP but with a return annotation " -> None" added to
Derived.foo. When I said this is fixed by adding an annotation I meant in the usual PEP 484 sense of type annotations, not decorators.tfranzel commentedon Nov 1, 2020
ahh sorry i somehow missed the link. i see, so the functionality is there. nonetheless kind of weird to only activate the check once a type hint is present.
JelleZijlstra commentedon Nov 1, 2020
I suppose this is because of mypy's general principle to not give errors for unannotated code. It feels like we should give the error if
--check-untyped-defsis on, though.[-]`@final` decorator is not honored. no error on override.[/-][+]`@final` decorator is not honored on override with --check-untyped-defs[/+]Check override compatibility for dynamically typed methods
Check override compatibility for dynamically typed methods
Validate more about overrides on untyped methods
Validate more about overrides on untyped methods (#17276)