[Import-SIG] What if namespace imports weren't special?

[Nick Coghlan]

On Wed, Jul 13, 2011 at 1:34 AM, P.J. Eby <pje at telecommunity.com> wrote:
> At 10:58 PM 7/12/2011 +1000, Nick Coghlan wrote:
>>
>> For the reasons you say - empty directories aren't handled well by
>> many tools and if the directory is going to have content, then
>> *somebody* has to define the rules for playing well with others, so it
>> may as well be us.
>>
>> However, I wrote this before reading PJE's last piece about virtual
>> packages. If that idea pans out (and I personally haven't spotted any
>> problems with it as yet) then we won't need a marker system at all, so
>> the point will become moot.
>
> True enough, but for the record, I like the idea.  I had previously thought
> of using a marker directory, but discarded it due to the fact that it seemed
> to make things more complicated to set up a package.  However, it occurs to
> me now that packaging tools can take responsibility for adding marker files
> to the directory, so for the end user, you just 'mkdir -p mypkg/py-pkg' or
> some such.  (I'm not keen on __package__ as the name; I'd rather something
> non-importable.  But that's a bikeshed for another time.)

I think we chose the colour of that particular bikeshed back when
__pycache__ was added :)

> I think one other thing that we can and should do with whatever approach we
> end up with, is to only require one level of marker.  There's virtually no
> benefit to restricting subpackage partitioning, because a subpackage's
> __path__ is always a subset of its parent's __path__.  So, as soon as you
> get down to something that only lives in a single directory, it'll be the
> same as if you'd restricted it.  Therefore, any drafts we do from this point
> forward should only require top-level markers.

+1 on having a multi-path parent imply multi-path support in subpackages.

Given the significant differences between the two approaches, perhaps
the marker directory idea should be written up as the "best of breed"
version of PEP 382 (probably under the name "partitioned packages"),
with a new PEP for the radically different "virtual packages"
alternative? I think publishing the two side-by-side will actually
help sell the virtual packages idea (Option A: Choose which flavour of
boilerplate you want to use to make your packages work; Option B: What
boilerplate?).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia