[MAL] > The module objects would be different, but that's just about it. [Gordon] > Which was exactly my point. Much code that does *not* use > "from ... import ..." in fact relies on having the same module object. [MAL] > You mean for e.g. hacking the module's globals ? If you consider a module maintaining pieces of its own state in its own globals as an instance of hacking the module's globals, yes, that's the main problem. For example (there are many, this isn't stretching), if the user ends up with two distinct copies of the tempfile module, its "global" _tempdir_lock becomes two distinct locks, and the truly global mutual exclusion _tempdir_lock was supposed to supply is lost. Ditto for the lock used internally by tempfile's global _counter object. The system-wide uniqueness of some globals is crucial to some modules' correct functioning.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4