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
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
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)
Right now we have several things to improve:
cpython/Lib/typing.py
Line 3490 in 4c87537
@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@classmethod
s, 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@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 (exceptstaticmethod
)PR is on its way :)
Linked PRs
typing.override
#102325The text was updated successfully, but these errors were encountered: