<p><br>
On Mar 14, 2012 11:56 PM, "Guido van Rossum" <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
><br>
> On Wed, Mar 14, 2012 at 8:33 PM, PJ Eby <<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>> wrote:<br>
> > On Mon, Mar 12, 2012 at 11:49 PM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> >><br>
> >> So the only backwards incompatibility is that "import foo" may succeed<br>
> >> where it previously failed if there is a directory foo/ somewhere on<br>
> >> sys.path but no foo.py and no foo/__init__.py anywhere. I don't think<br>
> >> this is a big deal.<br>
> ><br>
> ><br>
> > Actually, it *is* a big deal. An early draft of PEP 402 was like the<br>
> > newly-proposed approach, and it was shot down by an *actual code sample from<br>
> > a real package* that somebody posted to show the problem. The motivating<br>
> > example is actually presented in the PEP: trying to "import json" with a<br>
> > json/ directory present -- and the "json" package *not* present -- and then<br>
> > trying to use its contents. The PEP works around this by taking the<br>
> > namespace concept to its logical extreme and saying you can only import the<br>
> > *contents* of the namespace, because the namespace itself doesn't exist.<br>
> > (i.e., it's virtual.)<br>
> ><br>
> > tl;dr version: the killer problem with allowing "import foo" to succeed is<br>
> > that code which does try/except ImportError to test for a package's presence<br>
> > will get false positives. That's the motivating reason for only allowing<br>
> > sub-namespace package imports to succeed: it prevents the immediate breakage<br>
> > of real code, the moment the feature is introduced. :-(<br>
><br>
> Well, too bad. It's too much of a wart. Such try/except clauses make<br>
> me sad anyway -- and we're trying to get rid of them by e.g.<br>
> encouraging the pattern where heapq.py tries to import _heapq rather<br>
> than having user code try first _heapq and then heapq. (And the idiom<br>
> used in heapq.py doesn't mind if _heapq exists as an empty package.)</p>
<p>While I agree it is a wart, the heapq.py example might not be the best. A more real-world example might be the situation is PEP 417, where we'll be seeing people write</p>
<p>try:<br>
import unittest.mock<br>
except ImportError:<br>
import mock</p>
<p>And owning neither the two modules, the _ trick is not available.</p>
<p>I like the idea that if a package is only an implied namespace package, with no contents of it's own, it cannot itself be directly imported. This still allows the simple check, but without seriously modifying the new feature itself.</p>
<p>><br>
> --<br>
> --Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)<br>
> _______________________________________________<br>
> Import-SIG mailing list<br>
> <a href="mailto:Import-SIG@python.org">Import-SIG@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/import-sig">http://mail.python.org/mailman/listinfo/import-sig</a></p>