Re: PEP 420: Implicit Namespace Packages

On Sat, 5 May 2012 23:55:23 +1000
Nick Coghlan <[email protected]> wrote:
> 
> 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.

"Flat is better than nested" would indicate this is a virtue.

The stdlib's experiments with nested namespaces (e.g. urllib.request)
have turned out quite unpractical and clumsy IMHO.

Also, namespace packages have an authority problem: what happens if two
namespaces packages both define e.g. "foo/bar.py"? It works when you
have a central body, such as Zope or Eric's companies, but otherwise?

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

Would it? Why would it go into the "backports" package? Why favour this
category over another (e.g. "testing.unittest")?
You're soon gonna re-discover the limitations of hierarchical
classification :-)

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

Would you? You could just settle on the standard pkgutil boilerplate in
__init__.py.

Regards

Antoine.