-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
Typing: undocumented behaviour change for protocols decorated with @final
and @runtime_checkable
in 3.11
#103171
Comments
@final
and @runtime_checkable
in 3.11@final
and @runtime_checkable
in 3.11
My first instinct is to leave this as is. Marking Protocols as final is a weird thing to do in the first place (the whole point of protocols is to subclass from them, though usually implicitly). Adding more names to that |
This might be a bigger issue for PEP-702 though: what if you want to |
Sure. In that case, I think we should probably document the behaviour change with a |
Sure, that's fine. |
…ble protocols decorated with `@final`
I mark all things as So, I would consider this as a bug. |
I'm not sure that makes sense. The fact that Personally, I wasn't initially sure this new behaviour makes sense for |
@ilevkivskyi, do you have any opinions on how |
I haven't tried, but won't the change from #103160 fix this issue, because the |
Good point, #103160 does indeed fix this issue! I wasn't planning on backporting #103160 (if it's even accepted), though, as I was thinking of it as a performance optimisation (and it does change behaviour in a few other subtle ways, as discussed in the PR thread). So if #103160 is merged, that means that 3.12 will have the same behaviour as we had in 3.10 for |
FWIW I think protocols should not be final. So the behaviour change is fine. |
Maybe we should just add a note to the docs for |
But, they can be. What is the reason not to ignore I think that having an expected default behaviour in this case is easier than writting a warning in the docs. |
#103160 has now been merged, so it is just 3.11 that has the behaviour change now. |
I think we should fix 3.11 so that it excludes |
…ime-checkable protocols decorated with `@final`
…eckable protocols decorated with `@final` (#105445)
…ls decorated with `@final` Forward-port of the tests that were added to the 3.11 branch in python#105445
…ls dec orated with `@final` (pythonGH-105473) Forward-port of the tests that were added to the 3.11 branch in pythonGH-105445 (cherry picked from commit f5df347) Co-authored-by: Alex Waygood <[email protected]>
…ols decorated with `@final` (GH-105473) (#105474) Forward-port of the tests that were added to the 3.11 branch in GH-105445 (cherry picked from commit f5df347) Co-authored-by: Alex Waygood <[email protected]>
Python 3.11 introduced an undocumented behaviour change for protocols decorated with both
@final
and@runtime_checkable
. On 3.10:On 3.11:
This is because, following 0bbf30e (by @JelleZijlstra), the
@final
decorator sets a__final__
attribute wherever it can, so that it is introspectable by runtime tools. But the runtime-checkable-protocolisinstance()
machinery doesn't know anything about the__final__
attribute, so it assumes that the__final__
attribute is just a regular protocol member.This should be pretty easy to fix: we just need to add
__final__
to the set of "special attributes" ignored by runtime-checkable-protocolisinstance()
/issubclass()
checks here:cpython/Lib/typing.py
Lines 1906 to 1909 in 848bdbe
@JelleZijlstra do you agree with that course of action?
Linked PRs
@final
#103173@final
#105445@final
#105473@final
(GH-105473) #105474The text was updated successfully, but these errors were encountered: