<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 15, 2018 at 3:26 AM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 14 March 2018 at 15:20, Chris Billington <span dir="ltr"><<a href="mailto:chrisjbillington@gmail.com" target="_blank">chrisjbillington@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">I wonder if there's any reason something like this shouldn't be built into Python's default import system.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>There are two main challenges with enforcing such a check, one affecting end users in general, one affecting standard library maintainers in particular:<br><br></div><div>* 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.<br></div></div></div></div></blockquote><div><br></div><div>I call all such code "working"... It is a bad design.</div><div><br></div><div>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.</div><div><br></div><div>A cache by os.path.abspath would be a good thing.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>* 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"<br><br></div><div>I'm definitely sympathetic to the idea, though.<br></div></div><br clear="all"></div><div class="gmail_extra">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.</div></div></blockquote><div><br></div><div>I don't doubt that doing this would require a lot of code cleanup. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br></div><div class="gmail_extra"><br>[1] <a href="https://www.python.org/dev/peps/pep-0499/" target="_blank">https://www.python.org/dev/peps/pep-0499/</a></div></div><div dir="ltr"><div class="gmail_extra"><br><br>-- <br><div class="m_-6613425014321005070gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div></div>