On 14 March 2018 at 15:20, Chris Billington <chrisjbilling...@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. * 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. Cheers, Nick. [1] https://www.python.org/dev/peps/pep-0499/ -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
