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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
