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

Nick Coghlan ncoghlan at gmail.com
Thu Mar 15 06:25:22 EDT 2018

On 14 March 2018 at 15:20, Chris Billington <chrisjbillington at gmail.com>
> 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

* 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.

* 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.


[1] https://www.python.org/dev/peps/pep-0499/

Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180315/e915b701/attachment.html>

More information about the Python-ideas mailing list