Repository navigation
[typing] Runtime protocols with ClassVar data members should support issubclass #89138
Closed as not planned
Description
| BPO | 44975 |
|---|---|
| Nosy | @gvanrossum, @JelleZijlstra, @Fidget-Spinner |
| PRs |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/Fidget-Spinner'
closed_at = None
created_at = <Date 2021-08-22.08:56:49.329>
labels = ['type-feature', 'library', '3.11']
title = '[typing] Runtime protocols with ClassVar data members should support issubclass'
updated_at = <Date 2022-01-21.21:12:18.991>
user = 'https://github.com/Fidget-Spinner'bugs.python.org fields:
activity = <Date 2022-01-21.21:12:18.991>
actor = 'gvanrossum'
assignee = 'kj'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2021-08-22.08:56:49.329>
creator = 'kj'
dependencies = []
files = []
hgrepos = []
issue_num = 44975
keywords = ['patch']
message_count = 2.0
messages = ['400059', '411184']
nosy_count = 3.0
nosy_names = ['gvanrossum', 'JelleZijlstra', 'kj']
pr_nums = ['27883']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue44975'
versions = ['Python 3.11']
Activity
Fidget-Spinner commentedon Aug 22, 2021
This is a feature request by a user at python/typing#822.
A copy of their request:
Currently issubclass cannot be used for runtime_checkable protocols with data members, because those attributes could be set in __init__. I propose to relax this restriction to allow protocols with ClassVar members, as those should be present in the class definition.
I'm unsure if I need to update PEP-544 too. I don't remember if PEPs can be updated when 'Accepted', or was it 'Final' PEPs that can't be updated anymore?
gvanrossum commentedon Jan 21, 2022
IMO we shouldn't update PEP-544. PEPs reflect the historical proposal, they are not documentation for the current state of the interpreter.
hauntsaninja commentedon Oct 10, 2022
I'm -1 on implementing this feature.
In general, I believe stdlib should try to get out of the business of runtime type checking. Even with isinstance on runtime checkable protocols I've seen complaints about performance and unsoundness and interactions with descriptors. I don't think it's particularly intuitive for a runtime type check to only check presence of a ClassVar and then not check the type (and we definitely don't want to check the type).
gvanrossum commentedon Oct 10, 2022
So should we just deprecate
@runtime_checkable?hauntsaninja commentedon Oct 11, 2022
That's a good question!
Arguments in favour of keeping runtime_checkable:
Arguments in favour of deprecation:
Overall, one way forward would be to keep
runtime_checkable, but alias it to something that more clearly communicates the narrow scope. Maybe@isinstance_checks_methods_exist:-)hauntsaninja commentedon Oct 11, 2022
For this specific feature request, as Jelle says in https://github.com/python/cpython/pull/27883/files#r789976652 , we definitely shouldn't attempt to do type checking of the value. At most, we should validate attribute existence.
A claim that would make me neutral on checking for existence is if we believed that unsoundness related to the type being different is unlikely to be a problem. (With methods, I believe we've been mostly fine in practice because we check whether its a callable, which really narrows things down, plus callables aren't invariant)
gvanrossum commentedon Oct 11, 2022
Okay, let's close this one as won'tfix, and if someone feels strongly about the rest please open a new issue!