ExtensionFileLoader Does Not Implement invalidate_caches

[insertinterestingnamehere]

BPO	43819
Nosy	@insertinterestingnamehere

^{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 2021-04-12.20:54:59.834>
labels = ['type-bug', '3.9']
title = 'ExtensionFileLoader Does Not Implement invalidate_caches'
updated_at = <Date 2021-04-12.20:54:59.834>
user = 'https://github.com/insertinterestingnamehere'

bugs.python.org fields:

activity = <Date 2021-04-12.20:54:59.834>
actor = 'Ian.H'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2021-04-12.20:54:59.834>
creator = 'Ian.H'
dependencies = []
files = []
hgrepos = []
issue_num = 43819
keywords = []
message_count = 1.0
messages = ['390905']
nosy_count = 1.0
nosy_names = ['Ian.H']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue43819'
versions = ['Python 3.9']

[insertinterestingnamehere]

Currently there's no easy way to get at the internal cache of module spec objects for compiled extension modules. See

cpython/Python/import.c

Lines 401 to 415 in 20ac347

	/* Magic for extension modules (built-in as well as dynamically
	loaded). To prevent initializing an extension module more than
	once, we keep a static dictionary 'extensions' keyed by the tuple
	(module name, module name) (for built-in modules) or by
	(filename, module name) (for dynamically loaded modules), containing these
	modules. A copy of the module's dictionary is stored by calling
	_PyImport_FixupExtensionObject() immediately after the module initialization
	function succeeds. A copy can be retrieved from there by calling
	import_find_extension().
	Modules which do support multiple initialization set their m_size
	field to a non-negative number (indicating the size of the
	module-specific state). They are still recorded in the extensions
	dictionary, to avoid loading shared libraries twice.
	*/

. For example, these module spec objects continue to be cached even if we call importlib.invalidate_caches. ExtensionFileLoader doesn't implement the corresponding method for this.

The comment in the C file referenced above implies this is done this way to avoid re-initializing extension modules. I'm not sure if this can be fixed, but I figured I'd ask for input. Our use-case is an academic project where we've been experimenting with building an interface for linker namespaces into Python to allow for (among other things) loading multiple copies of any module without explicit support from that module. We've been able to do this without having custom builds of Python. We've instead gone the route of overriding some of the import machinery at runtime. To make this work we need a way to prevent caching of previous import-related information about a specific extension module. We currently have to rely on an unfortunate hack to get access to the internal cache of module spec objects for extension modules and modify that dictionary manually. What we have works, but any sort of alternative would be welcome.