[Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

[Nick Coghlan]

On Fri, Jul 22, 2011 at 11:04 AM, Antoine Pitrou <solipsis at 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 <solipsis at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia