PEP 698 typing.override
A few weeks back we merged PEP 698 for `typing.override` as a draft PEP, with no significant changes since the typing-sig discussion in [1] One of the things we decided for the initial proposal was to avoid any runtime behavior; we considered setting `__override__` but decided not to because (a) it is hard to get the ordering of decorators right for runtime behavior, it depends on which decorators are descriptor- versus wrapper-function-based (b) some objects have fixed slots and therefore cannot have `__override__` set at all, there's no way to produce runtime behavior in these cases I think we should reconsider for two reasons: (a) The author of the overrides library got back to us and specifically requested this [2], because he believes there's potential for libraries to make runtime use of @override, for example automatically applying docstrings from parent classes to child classes which could be useful for notebook users (b) We do indeed set a `__final__` attribute in the @final decorator [3], and after some more thought I think consistency is important My current opinion is that we should make a best-effort attempt to set the attribute (as we do in `@typing.final`) and document edge cases that can impact runtime behavior, while ignoring those edge cases in static checkers. Are there any objections before I start working on these changes? ------------------- [1] Previous thread about typing.override proposal: https://mail.python.org/archives/list/typing-sig@python.org/message/7JDW2PKG... [2] Discussion in peps repo regarding `__override__` https://github.com/python/peps/pull/2830 [3] @typing.final logic today: https://github.com/python/cpython/blob/main/Lib/typing.py#L2630-L2636
SGTM. Interesting that the PEP for @final did not have a runtime effect but the implementation ended up adding it -- seems a good idea to avoid that mistake this time. On Tue, Oct 11, 2022 at 4:20 PM Steven Troxler <steven.troxler@gmail.com> wrote:
A few weeks back we merged PEP 698 for `typing.override` as a draft PEP, with no significant changes since the typing-sig discussion in [1]
One of the things we decided for the initial proposal was to avoid any runtime behavior; we considered setting `__override__` but decided not to because (a) it is hard to get the ordering of decorators right for runtime behavior, it depends on which decorators are descriptor- versus wrapper-function-based (b) some objects have fixed slots and therefore cannot have `__override__` set at all, there's no way to produce runtime behavior in these cases
I think we should reconsider for two reasons: (a) The author of the overrides library got back to us and specifically requested this [2], because he believes there's potential for libraries to make runtime use of @override, for example automatically applying docstrings from parent classes to child classes which could be useful for notebook users (b) We do indeed set a `__final__` attribute in the @final decorator [3], and after some more thought I think consistency is important
My current opinion is that we should make a best-effort attempt to set the attribute (as we do in `@typing.final`) and document edge cases that can impact runtime behavior, while ignoring those edge cases in static checkers.
Are there any objections before I start working on these changes?
-------------------
[1] Previous thread about typing.override proposal:
https://mail.python.org/archives/list/typing-sig@python.org/message/7JDW2PKG...
[2] Discussion in peps repo regarding `__override__` https://github.com/python/peps/pull/2830
[3] @typing.final logic today: https://github.com/python/cpython/blob/main/Lib/typing.py#L2630-L2636 _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: guido@python.org
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
Hi, the maintainer of overrides lib here Great if @override with runtime effect is getting into 3.12! The PEP draft currently has this section https://github.com/python/peps/blob/main/pep-0698.rst#runtime-override-check... With the following:
Today, there is an Overrides library that provides decorators @overrides (sic) and @final and will enforce them at runtime. PEP 591 added a @final decorator with the same semantics as those in the Overrides library. But the override component of the runtime library is not supported statically at all, which has added some confusion around the mix/matched support.
I now added an alias `@override` for the original decorator. Also for Python 3.11 that will have runtime effect for `@final` and I *finally* could use the typing.final decorator directly - so that should solve the confusion around the mix/matched support. I hope these will make it easier for the users of the overrides library to enter Python 3.12 world where there would be an inbuilt typing.override to use. Most usage of overrides library today seems to be in Python 3.7 still so might take some time for the new Python 3.12 (to be released in 2023) to get mainstream.
As of now, we - updated both pyre_extensions and typing_extensions to make a best-effort attempt set an `__override__` attribute [1] - updated PEP 698 to include this runtime behavior in the specification [2] As far as I know there are no other requests for changes so far. What are the next steps for this proposal? Given the relative lack of runtime behavior I'm not certain whether we post to python-dev before submitting this for review or the discussion stays here on typing-sig. Cheers, Steven
El sáb, 5 nov 2022 a las 10:21, Steven Troxler (<steven.troxler@gmail.com>) escribió:
As of now, we
- updated both pyre_extensions and typing_extensions to make a best-effort attempt set an `__override__` attribute [1] - updated PEP 698 to include this runtime behavior in the specification [2]
As far as I know there are no other requests for changes so far.
What are the next steps for this proposal? Given the relative lack of runtime behavior I'm not certain whether we post to python-dev before submitting this for review or the discussion stays here on typing-sig.
The PEP should be posted on discuss.python.org under the PEPs category for feedback. We no longer use the python-dev mailing list as the main forum for PEP discussions. After that, assuming there are no major issues, the PEP can be submitted to the SC for a decision.
Cheers, Steven _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com
PEP 698 has been posted at discuss.python.org: https://discuss.python.org/t/pep-698-a-typing-override-decorator/20839 So far there's only one question, which is about the idea of letting users include the base class name in the decorator, and validating that it is overriding a method on that specific class. It is probably best to discuss there rather than here. Many thanks to Jelle for all the help getting the PEP to this point, as well as to all of you for feedback on the initial idea and early drafts!
El mar, 8 nov 2022 a las 7:58, Steven Troxler (<steven.troxler@gmail.com>) escribió:
PEP 698 has been posted at discuss.python.org: https://discuss.python.org/t/pep-698-a-typing-override-decorator/20839
So far there's only one question, which is about the idea of letting users include the base class name in the decorator, and validating that it is overriding a method on that specific class.
I'm not opposed to this idea if a lot of users ask for it, but it feels very niche and I'd prefer to keep it out of the initial proposal. This feature can always be added later if there's widespread demand for it.
It is probably best to discuss there rather than here.
Many thanks to Jelle for all the help getting the PEP to this point, as well as to all of you for feedback on the initial idea and early drafts! _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com
PEP 698 is accepted! See https://discuss.python.org/t/pep-698-a-typing-override-decorator/20839/11. Work still to be done: - I need to update the typing module in CPython and then typeshed, I'll report back here when that is finished - Once those changes land we'll want to re-export typing.override from typing_extensions in newer version of Python - I'll extend Pyre's support for `@override` to allow `typing.override`, we'll want to do the same for other type checkers Thanks to all of you for their feedback and support with this proposal! Cheers, Steven
participants (4)
-
Guido van Rossum -
Jelle Zijlstra -
Mikko Korpela -
Steven Troxler