Add __override__ attribute to @override (PEP 698)
#86
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As per discussion in https://mail.python.org/archives/list/[email protected]/thread/TOIYZ3SNPBJZDBRU3ZSBREXV2NNHF4KW/, we believe this is a good feature to have (as best-effort: it will not work in all cases if the user does not understand decorator implementations enough to get the right order, and it will alwasys fail if a decorator output does not support dynamic attributes). We decided to support this for two reasons: - it was a direct request from the `overrides` library owner - `typing_extensions.final` has similar behavior Tests: ``` cd src python -m unittest test_typing_extensions.py ``` Lints: ``` flake8 flake8 --config=.flake8-tests src/test_typing_extensions.py ```
stroxler
changed the title
__override__ attribute to @override__override__ attribute to @override (PEP 698)
Contributor
Author
stroxler
added a commit
to stroxler/peps
that referenced
this pull request
Oct 28, 2022
We decided to add this for two reasons: - It was specifically requested by the author of the `overrides` library, because there there are some handy runtime uses of override information (such as propagating docstrings, which we highlight as a concrete example) - We realized that we actually added `__final__` to `@typing.final` in spite of it not being specified in PEP 591, which we felt strongly suggests that even if we omit it we would later change our minds. This runtime behavior is currently implemented in typing_extensions (see python/typing_extensions#86) as well as pyre_extensions.
JelleZijlstra
pushed a commit
to python/peps
that referenced
this pull request
Oct 28, 2022
We decided to add this for two reasons: - It was specifically requested by the author of the `overrides` library, because there there are some handy runtime uses of override information (such as propagating docstrings, which we highlight as a concrete example) - We realized that we actually added `__final__` to `@typing.final` in spite of it not being specified in PEP 591, which we felt strongly suggests that even if we omit it we would later change our minds. This runtime behavior is currently implemented in typing_extensions (see python/typing_extensions#86) as well as pyre_extensions.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As per discussion in
https://mail.python.org/archives/list/[email protected]/thread/TOIYZ3SNPBJZDBRU3ZSBREXV2NNHF4KW/, we believe this is a good feature to have (as best-effort: it will not work in all cases if the user does not understand decorator implementations enough to get the right order, and it will alwasys fail if a decorator output does not support dynamic attributes).
We decided to support this for two reasons:
overrideslibrary ownertyping_extensions.finalhas similar behaviorTests:
Lints:
I'll edit PEP 698 to cover this behavior this week, but I wanted to get feedback here and back-port to pyre_extensions first so that we can have the runtime behavior linked in the reference implementation.
I tried to include a test of a decorator with
__slots__, but I don't know descriptors that well and got stuck. I can add that if we really want it but wasn't sure I wanted to spend the time otherwise. I would guess that most of the time when the runtime behavior fails it will be due to out-of-order decorators rather than output types that have fixed slots, so my static method examples seem more useful as edge-case documentation.