On Thu, Mar 15, 2018 at 3:26 AM Nick Coghlan <ncogh...@gmail.com> wrote:
> 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. > 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 | 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/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
