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

[Nick Coghlan]

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). Java doesn't
suffer from it since the cost is incurred at compile time, and I
believe there are differences in the way Perl and PHP work that make
it less of an issue there as well.

PJE's latest PEP update clearly articulates the semantics for a
"non-conflicting marker file" approach (modulo a name change to
<contributing-distribution>.pyp or .pypart instead of
<contributing-distribution>.ns).

Allowing unmarked directories to count as packages has already been
rejected in the past due to the problem of hiding package directories
later on sys.path. Given the performance penalty that rules out
"partitioned by default", this rejection remains in force.

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.

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.

Cheers,
Nick.

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