GeezerVison is showing github.com — [typing] Runtime protocols with ClassVar data members should support issubclass · Issue #89138 · python/cpython
[typing] Runtime protocols with ClassVar data members should support issubclass #89138Description
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'] ActivityFidget-Spinner commented on 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 commented on 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 commented on 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). Reacted by Jelle Zijlstra gvanrossum commented on Oct 10, 2022 So should we just deprecate @runtime_checkable? hauntsaninja commented on Oct 11, 2022 That's a good question!
Arguments in favour of keeping runtime_checkable:
- The "protocols" people are most familiar with are the ones in collections.abc. These support isinstance, so perhaps it'd be surprising if custom protocols didn't have an analogue available to them (that said, the abcs also have virtual subclassing, which type checkers and protocols do not support)
- Without isinstance for protocols, it becomes more important that type checkers understand hasattr checks (mypy only gained support for this recently)
- Empirically, unsoundness related to method signatures hasn't proven to be a big problem. Aka if the method exists and it's callable, it seems it's usually got a signature that's compatible enough
- I don't like deprecating functionality when there isn't a clear alternative
Arguments in favour of deprecation:
- Runtime type checking is heavily contentious. It's mostly impossible to make things sound or performant, let alone both
- By pushing users to look outside of the standard library, it's easier for users to opt-in to the exact behaviour they want, and for the ecosystem to experiment with different tradeoffs and avoid backwards compatibility concerns
- isinstance is one of the hottest functions in most codebases I've worked on, so it's nice not to encourage adding potential performance pitfalls to it
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 commented on 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 commented on 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!
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|