On Fri, Jul 22, 2011 at 11:04 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > > Le vendredi 22 juillet 2011 à 10:58 +1000, Nick Coghlan a écrit : >> On Fri, Jul 22, 2011 at 10:00 AM, Antoine Pitrou <solip...@pitrou.net> wrote: >> > Wouldn't it produce confusing situations like the above example? >> >> I don't see how it is any more confusing than any other form of module >> shadowing. > > The additional confusion lies in the fact that a module can be shadowed > by something which is not a module (a mere global variable). I find it > rather baffling.
It's still an improvement on current Python. There a submodule can be shadowed uselessly by something that doesn't even exist. For example: x.py <-- No 'y' attribute x/__init__.py <-- not needed in PEP 402 x/y.py from x import y <-- ImportError now, but would work in PEP 402 However, this does highlight an interesting corner case not yet covered by the PEP: when building a virtual path to add to an existing module, what do we do with directories that contain __init__.py[co] files? 1. Ignore the entire directory (i.e leave it out of the created path)? (always emit ImportWarning) 2. Ignore the file and add the directory to the created path anyway? (never emit ImportWarning) 3. Ignore the file and add the directory to the created path anyway? (emit ImportWarning if __init__.py is not empty) 4. Ignore the file only if it is empty, otherwise ignore the whole directory? (emit ImportWarning if __init__.py is not empty) 5. Execute the file in the namespace of the existing module? I suspect option 1 will lead to the fewest quirks, since it preserves current shadowing behaviour for modules and self-contained packages. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
