On 6 August 2015 at 10:07, Cameron Simpson cs@zip.com.au wrote:
I suspect "How Reloading Will Work" would need to track both module.__name__ and module.__spec__.name to reattach the module to both entires in sys.modules.
Conveniently, the fact that reloading rewrites the global namespace of the existing module, rather than creating the new module, means that the dual references won't create any new problems relating to multiple references - we already hit those issues due to the fact that modules refer directly to each from their module namespaces.
I'd like to have a go at addressing just the change I outline above, in the interests of just getting it done. Is that too narrow a change or PEP topic?
PEPs can be used for quite small things if we want to check for edge cases, and the interaction between __main__ and the rest of the import system is a truly fine source of those :)
Are there specific other things I should be considering/addressing that might be affected by my suggestion?
Using __spec__.name for pickling: http://bugs.python.org/issue19702 Proposed runpy refactoring to reduce the special casing for __main__: http://bugs.python.org/issue19982
Also, where do I find to source for runpy to preruse?
It's a standard library module: https://hg.python.org/cpython/file/default/Lib/runpy.py
"_run_module_as_main" is the module level function that powers the "-m" switch.
Actually *implementing* this change should be as simple as changing the line:
main_globals = sys.modules["__main__"].__dict__
to instead be:
main_module = sys.modules["__main__"] sys.modules[mod_spec.name] = main_module main_globals = main_module.__dict__
The PEP is mainly useful to more widely *advertise* the semantic change, since having the module start being accessible under both names has the potential to cause problems. In particular, I'll upgrade the pickle issue to something that *needs* to be addressed before this change can be made, as there will be programs that are working today because they'll be dual importing the main module, and then pickling objects from the properly imported one, which then unpickle correctly in other processes (even if __main__ is different).
Preventing the dual import without also fixing the pickle compatibility issue when pickling __main__ objects would thus have the potential to break currently working code.
Cheers, Nick.