Doubley imported module caused devastating bug

[Carl Banks]

On Sep 24, 10:26 am, Zac Burns <zac... at 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