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

[P.J. Eby]

At 05:32 PM 7/11/2011 +1000, Nick Coghlan wrote:
>On Mon, Jul 11, 2011 at 5:04 PM, Eric Snow 
><ericsnowcurrently at gmail.com> wrote:
> > FWIW, I think the solution in the PEP is the clearest approach, if
> > "partitioned by default" is not an option.  And if that and the other
> > alternate solutions are not feasible, it would be nice to have them
> > added to the "rejected" section because they are still reasonable
> > ideas.  Still, it would be nice if we didn't have to add a new
> > packageness indicator.
>
>The runtime performance impact kills "partitioned by default" (i.e. no
>marker files needed to indicate partitioned packages).

Actually, partitioned by default is the *best* performance option we 
have for implementing this PEP, because it only uses a stat rather 
than a listdir.  Backward compatibility is the thing that kills it.

That's why I made the more recent "py-pkg/" proposal -- it has the 
same degree of backward compatibility as flag files does, but keeps 
the improved performance of partitioning by default.


>One question then is whether, given that a partitioned package has
>already been identified, should unmarked directories later on sys.path
>count as part of that package? My answer is no, as this is the only
>answer that provides consistent behaviour. Otherwise, unmarked
>directories may or may not be detected as part of the package
>depending on whether or not a partitioned package directory was found
>earlier on the path.

This is already in the PEP draft I wrote, and it's definitely the 
correct semantics for marker files approach.  The py-pkg approach of 
course works similarly, since the py-pkg directory is the "marker" in 
that case.


>As far as the specific suggestion of using a "marker directory"
>instead of marker files goes, I don't really see the benefit (and
>plenty of downsides). I put it in the same category as using a special
>extension on the directory name (since that's what it is, only using
>"/" as the separator instead of ".") and reject it for the same
>reasons.

What are the downsides, exactly?  Special extensions don't work with 
the distutils; a prefix does.  (I've tested it.)  Most tools that 
look for code can be given a prefix to look for the code, but not an 
extension.  It's *quite* a different proposition than specially-named 
directories -- especially since only the package root is affected, 
not every subpackage directory.