On Sep 24, 10:26 am, Zac Burns <zac...@gmail.com> wrote: > Currently it is possible to import a file of one path to more than one > 'instance' of a module. One notable example is "import __init__" from > a package. > Seehttp://stackoverflow.com/questions/436497/python-import-the-containin... > > This recently caused a devastating bug in some of my code. What I have > is support for the Perforce global options as a context for a perforce > module.http://www.perforce.com/perforce/doc.072/manuals/cmdref/o.gopts.html#... > This way one can call functions that call many perforce command and > have them execute on a different client for example. > > So, in module A and module B both imported the Perforce module, but > they turned out not to be the same module. Module A did "with > Perforce.GlobalOptions(client=client): B.function()" > > B.function did not receive the new GlobalOptions because of this > problem. As a result important files on the original client were > overwritten (OUCH). > > I would like to propose that it be made impossible in the Python > source to import two instances of the same module.
Impossible's a pretty strong word. It's a reasonable request, but with Python's importing the way it is it'd be kind of hard to do. A Python file can be visible in multiple ways. However, anyone who does "import __init__" (or "from . import __init__" with relative import) is asking for trouble, I can't think of any valid reason to do it, and I wouldn't mind seeing that forbidden, but it's simple to avoid. Someone probably did that because they didn't know how to import a containing package from one of its modules, failing to realize that it created a new module. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list