GeezerVison is showing github.com — Convert importlib.abc to use typing.Protocol · Issue #82963 · python/cpython
Convert importlib.abc to use typing.Protocol #82963Description
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 = None
closed_at = None
created_at = <Date 2019-11-12.22:47:40.242>
labels = ['type-feature', 'library', '3.9']
title = 'Convert importlib.abc to use typing.Protocol'
updated_at = <Date 2021-10-20.21:07:21.258>
user = 'https://github.com/brettcannon' bugs.python.org fields:
activity = <Date 2021-10-20.21:07:21.258>
actor = 'barry'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2019-11-12.22:47:40.242>
creator = 'brett.cannon'
dependencies = []
files = []
hgrepos = []
issue_num = 38782
keywords = ['patch']
message_count = 1.0
messages = ['356501']
nosy_count = 5.0
nosy_names = ['barry', 'brett.cannon', 'levkivskyi', 'ZackerySpytz', 'nanjekyejoannah']
pr_nums = ['21245']
priority = 'low'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue38782'
versions = ['Python 3.9'] Activitybrettcannon commented on Nov 12, 2019 Now that typing.Protocol exists we should convert the ABCs in importlib over to protocols as the import system functions off of structural typing and not nominal typing. JelleZijlstra commented on Apr 30, 2022 Protocols are a better conceptual fit for these classes, but wouldn't this change break backwards compatibility? For example, protocols don't support .register(). brettcannon commented on May 1, 2022 Probably, which is why I figured the protocols would be separate since the ABCs also have default implementations that the protocols wouldn't have (I just forgot to update the issue with my latest thinking 😅). I had not decided if they should be in a separate module or just stick them in importlib.abc. brettcannon commented on Jun 6, 2025
protocols don't support .register()
Doesn't using ABCMeta get Protocol subclasses access to register()?
|
class Protocol(Generic, metaclass=_ProtocolMeta): |
|
class _ProtocolMeta(ABCMeta): |
ilevkivskyi commented on Jun 12, 2025 Yes, IIRC protocols a supposed to be "drop in" replacement for ABCs, in particular .register() support is tested here
|
def test_protocols_support_register(self): |
That said however, most type-checkers don't support .register() well (or at all). brettcannon commented on Jun 12, 2025
That said however, most type-checkers don't support .register() well (or at all).
It would just be for the legacy ABC support. My expectation is the current ABCs will inherit from the protocols, but that most code will type to the protocols themselves and the type checkers will rely on that. But I would still have to either leave the abstract methods that are already there on the ABCs or use @abc.abstractmethod on the protocol classes themselves. Otherwise the protocols might as well be kept separate, in which case it's a question of where to put them in the importlib namespace.
Since I have not written it down, the protocols/types will be for:
sys.meta_path finderssys.path finders- Loaders
sys.path_hook callables FFY00 commented on Feb 25, 2026 So, for the protocols, do we keep the ABC names? It would be a bit weird to have two different types with the same name, but coming up with new names for the protocols seems silly.
Here are the ABC types that would need a protocol:
MetaPathFinderPathEntryFinderLoaderResourceLoaderInspectLoaderExecutionLoaderFileLoaderSourceLoader
Here are the new protocols we would need for the rest of the import machinery:
Importer (MetaPathFinder + Loader)PathHook (Callable[[str], Finder])
That said, ResourceLoader is currently deprecated in favor of TraversableResources. Should we be creating a new protocol for ResourceLoader? If we don't, its subtypes probably also need to be omitted.
ResourceLoader and its subtypes implement a couple APIs that overlap with the new abstractions:
ResourceLoader.get_data -> TraversableInspectLoader.get_source -> TraversableInspectLoader.is_package -> Traversable.is_dirExecutionLoader.get_filename -> TraversableSourceLoader.set_data -> Traversable
They could be replaced with a single loader protocol implementing:
InspectLoader.get_codeTraversableResources.filessource_to_code (is static, could be provided standalone)
And extending Traversable with the following APIs:
I guess this issue converges towards GH-89710.
With the introduction of Traversable, most of the old APIs became redundant.
If we are introducing protocols, I am not sure if it makes sense to keep the old PEP 302 APIs. brettcannon commented on Feb 25, 2026 I think protocols like FinderLike and LoaderLike makes sense. There can be a type for path hooks if we want. So I agree on new names and I'm personally fond of the "*Like" style of naming (hence os.PathLike 😁).
As for all the PEP 302 protocols, I say skip them.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|