Re: PEP 420: Implicit Namespace Packages

On Sat, May 5, 2012 at 11:37 PM, Antoine Pitrou <[email protected]> wrote:
> The lack-of-prettiness argument is quite underwhelming when there are
> so few projects using namespace packages; and this is not something you
> see when you only *use* the package, rather than develop it.

No, it's a chicken-and-egg problem. Yes, namespace packages *are*
possible now, but they're a PITA to coordinate (everybody has to play
by the rules and put the right magic incantation in their __init__.py
files). So, people avoid them because they're a pain, not because
they're necessarily a bad idea (when used appropriately).

However, the problem isn't with the concept of namespace packages,
it's with the current awkward *implementation*.

Both PEP 382 and 420 fix the ugliness problem and bring namespace
packages up to a standard where I'd be happy seeing them used in the
standard library (MvL has proposed that "encodings" would be a good
candidate for that, and I'm inclined to agree).

A clean collaborative namespace system also helps with the evolution
of informal taxonomies on PyPI. You can see this on CPAN, where file
related modules are all in File::, email related ones are in Email::,
etc. At the moment, pretty much everything ends up being a top-level
module on PyPI, *because* namespace packages are so awkward and
unintuitive.

If those of us that do stdlib backports like contextlib2, unittest2
and distutils2 could just as easily publish backports.contextlib,
backports.unittest and backports.packaging, that would make it *much*
clearer to the world what is going on. None of us are willing to do
that at the moment, because we'd have to coordinate the installation
of backports.__init__, instead of being able to just include an
additional directory in our path names.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia