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

P.J. Eby pje at telecommunity.com
Tue Jul 12 17:34:49 CEST 2011

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 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.

More information about the Import-SIG mailing list