[Import-SIG] What if namespace imports weren't special?
pje at telecommunity.com
Mon Jul 11 17:25:40 CEST 2011
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
>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
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.
More information about the Import-SIG