Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add @typing.override #78

Merged
merged 7 commits into from Oct 6, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 2 additions & 0 deletions CHANGELOG.md
Expand Up @@ -5,6 +5,8 @@
and Jelle Zijlstra). Patch by James Hilton-Balfe (@Gobot1234).
- Add initial support for TypeVarLike `default` parameter, PEP 696.
Patch by Marc Mueller (@cdce8p).
- Runtime support for PEP 698, adding `typing_extensions.override`. Patch by
Jelle Zijlstra.
- Add the `infer_variance` parameter to `TypeVar`, as specified in PEP 695.
Patch by Jelle Zijlstra.

Expand Down
16 changes: 16 additions & 0 deletions src/test_typing_extensions.py
Expand Up @@ -29,6 +29,7 @@
from typing_extensions import assert_type, get_type_hints, get_origin, get_args
from typing_extensions import clear_overloads, get_overloads, overload
from typing_extensions import NamedTuple
from typing_extensions import override
from _typed_dict_test_helper import FooGeneric

# Flags used to mark tests that only apply after a specific
Expand Down Expand Up @@ -160,6 +161,21 @@ def test_exception(self):
assert_never(None)


class OverrideTests(BaseTestCase):
def test_override(self):
class Base:
def foo(self): ...

class Derived(Base):
@override
def foo(self):
return 42

self.assertIsSubclass(Derived, Base)
self.assertEqual(Derived().foo(), 42)
JelleZijlstra marked this conversation as resolved.
Show resolved Hide resolved
self.assertEqual(dir(Base.foo), dir(Derived.foo))


class AnyTests(BaseTestCase):
def test_can_subclass(self):
class Mock(Any): pass
Expand Down
31 changes: 31 additions & 0 deletions src/typing_extensions.py
Expand Up @@ -62,6 +62,7 @@
'Literal',
'NewType',
'overload',
'override',
'Protocol',
'reveal_type',
'runtime',
Expand Down Expand Up @@ -2078,6 +2079,36 @@ def decorator(cls_or_fn):
return decorator


if hasattr(typing, "override"):
override = typing.override
else:
_F = typing.TypeVar("_F", bound=typing.Callable[..., typing.Any])

def override(__arg: _F) -> _F:
Comment on lines +2085 to +2087
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just asking, my understanding was that types should not be added here and only provided via typeshed. I can't find a reference for it unfortunately. Did I miss something?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is true that type checkers will not look at this code. But types have value as documentation and perhaps some niche value for dynamic introspection.

"""Indicate that a method is intended to override a method in a base class.

Usage:

class Base:
def method(self) -> None: ...
pass

class Child(Base):
@override
def method(self) -> None:
super().method()

When this decorator is applied to a method, the type checker will
validate that it overrides a method with the same name on a base class.
This helps prevent bugs that may occur when a base class is changed
without an equivalent change to a child class.
Comment on lines +2103 to +2104
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This helps prevent bugs that may occur when a base class is changed
without an equivalent change to a child class.
This helps prevent bugs that may occur when a method on a base class is renamed
without an equivalent change to a child class.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer the current more general wording. For example, the base class method could be removed instead of renamed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, good point. Ignore this then :)


See PEP 698 for details.

"""
return __arg


# We have to do some monkey patching to deal with the dual nature of
# Unpack/TypeVarTuple:
# - We want Unpack to be a kind of TypeVar so it gets accepted in
Expand Down