[Python-Dev] Pre-PEP: Redesigning extension modules

[Terry Reedy]

On 8/24/2013 8:51 AM, Stefan Behnel wrote:
> Antoine Pitrou, 24.08.2013 13:53:
>> This would also imply extension module have to be subclasses of the
>> built-in module type. They can't be arbitrary objects like Stefan
>> proposed. I'm not sure what the latter enables, but it would probably
>> make things more difficult internally.
>
> My line of thought was more like: if Python code can stick anything into
> sys.modules and the runtime doesn't care, why can't extension modules stick
> anything into sys.modules as well?

Being able to stick anything in sys.modules in CPython is an 
implementation artifact rather than language feature.

"sys.modules
This is a dictionary that maps module names to modules which have 
already been loaded."

This implies to me that an implementation could use a dict subclass (or 
subtype if you prefer) that checks that keys are names and values 
ModuleType instances (or None).

"This can be manipulated to force reloading of modules and other tricks."

I guess this refers to the undocumented (at least here) option of None 
as a signal value.

> I can't really see the advantage of requiring a subtype here. Or even just
> a type, as I said.

A 'module' has to work with the import machinery and user code. I would 
ask, "What is the advantage of loosening the current spec?" (Or 
reinterpreting 'module', if you prefer.)  Loosening is hard to undo once 
done.

-- 
Terry Jan Reedy