Terry J. Reedy added the comment: I don't understand the statement that having 'import email.charset' set email.charset is an optional side effect. Without the name setting, the module is inaccessible except through sys.modules, which is not obvious to beginners. To me, making a module directly accessible is the main point of an import. As it is now, the second 'import email.charset' in the example is equivalent to 'pass'.
The test example is simplified to show the core behavior. The real life problem arises when the second 'import package.submodule' is in a different module, perhaps the main module, or in the case of an IDE such as IDLE, in user code exec()ed as is it were running in a main module. When a module runs 'import pack.sub' (for now, only the first time), the 'pack' module is 'monkey-patched' by externally injecting 'sub'. After this, without a deletion, the normally buggy "import pack; print(pack.sub)" executed anywhere in the process will work. Since June 2015, there have been 4 StackOverflow questions about IDLE giving implicit false positives by running code that fails when run directly in Python. I believe that this is more questions during this period than for any other IDLE issue. Currently, if a module author tries to be conscientious and clean up any injections it caused, then the process-global effect is to disable normally correct code. The point of this issue, however classified, is to make it possible for a module to access the modules of a different package without causing mysterious action-at-a-distance effects. Sorry I did not initially explain this better here. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27515> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
