Right now we have several things to improve:
- This branch is not covered by tests:
We don't have a single test that ensures that
@override will not fail for some weird cases. Since 99.99% of use-cases will simply be @override def some(...): ..., it is not very important - but still desirable
- We don't test
@classmethods, I guess it is special enough to be included
@property is also missing from tests, but is mentioned in PEP: https://peps.python.org/pep-0698/#specification and https://peps.python.org/pep-0698/#limitations-of-setting-override
- PEP also mentions
@functools.lru_cache and similar decorators as an example of how wrappers should be nested. Why don't we test it? Right now there are no tests for nested method decorators (except staticmethod)
- It might not hurt to test that parent's methods definitions are not mutated (I think this is a part of the contract)
PR is on its way :)
Linked PRs
Right now we have several things to improve:
cpython/Lib/typing.py
Line 3490 in 4c87537
@overridewill not fail for some weird cases. Since 99.99% of use-cases will simply be@override def some(...): ..., it is not very important - but still desirable@classmethods, I guess it is special enough to be included@propertyis also missing from tests, but is mentioned in PEP: https://peps.python.org/pep-0698/#specification and https://peps.python.org/pep-0698/#limitations-of-setting-override@functools.lru_cacheand similar decorators as an example of how wrappers should be nested. Why don't we test it? Right now there are no tests for nested method decorators (exceptstaticmethod)PR is on its way :)
Linked PRs
typing.override#102325