[Python-ideas] Disallow importing the same module under multiple names

Gregory P. Smith greg at krypto.org
Tue Mar 20 02:25:23 EDT 2018


On Thu, Mar 15, 2018 at 3:26 AM Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 14 March 2018 at 15:20, Chris Billington <chrisjbillington at gmail.com>
> wrote:
>>
>> I wonder if there's any reason something like this shouldn't be built
>> into Python's default import system.
>>
>
> There are two main challenges with enforcing such a check, one affecting
> end users in general, one affecting standard library maintainers in
> particular:
>
> * the user facing problem is a backwards compatibility one: while
> double-imports usually aren't what people wanted, they're also typically
> fairly harmless. As a result, elevating them from "sometimes a source of
> obscure bugs" to "categorically prohibited" risks breaking currently
> working code. While a conventional deprecation cycle should be possible, it
> isn't clear whether or not the problem occurs frequently enough to warrant
> that effort.
>

I call all such code "working"... It is a bad design.

They are not harmless for any module that initializes global state or
defines exceptions or types and relies on catching those exceptions or
types via isinstance checks when things created in one part of the program
wind up used in another that refers to a different multiply imported copy
of the module. This is even more painful for extension modules. Debugging
these issues is hard.

A cache by os.path.abspath would be a good thing.

I'd personally prefer it to be an ImportError with a message explaining the
problem. Including a pointer to the original successful import when the
import under another sys.modules name is attempted. It'd lead to better
code health. But others likely disagree and prefer to silently return the
existing module.


> * the maintainer level problem is that we actually do this on purpose in
> the standard library's test suite in order to test both pure Python and C
> accelerated variants of various modules. That could be handled by being
> careful about exactly where the reverse lookup cache from filenames back to
> module names is checked and updated, but it does make the problem a bit
> trickier than just "maintain a reverse lookup table from filesystem paths
> to module names and complain if an import gets a hit in that table"
>
> I'm definitely sympathetic to the idea, though.
>
> If we did head in this direction, then we'd also need to accept &
> implement PEP 499 [1] (which proposes aliasing __main__ as
> __main__.__spec__.name in sys.modules when executed with "-m") to avoid
> causing problems.
>

I don't doubt that doing this would require a lot of code cleanup. :)


>
> Cheers,
> Nick.
>
> [1] https://www.python.org/dev/peps/pep-0499/
>
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180320/d92eede7/attachment.html>


More information about the Python-ideas mailing list