[Import-SIG] PEP 420: Implicit Namespace Packages
solipsis at pitrou.net
Sat May 5 16:23:11 CEST 2012
On Sat, 5 May 2012 23:55:23 +1000
Nick Coghlan <ncoghlan at gmail.com> 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
"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
> 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
More information about the Import-SIG