[Python-Dev] PEP 423 : naming conventions and recipes related to packaging

[Paul Moore]

On 27 June 2012 13:20, Paul Moore <p.f.moore at gmail.com> wrote:
> I agree. I only skimmed the PEP, but even on a skimming, I got the
> impression that it was promoting the use of namespaces for ownership,
> in a Java-like way. The part Nick quoted is substantially more
> reasonable (assuming that's a direct quote, rather than Nick's
> summarisation) but the principle should be made clear right at the
> top.

Reading in a bit more depth, I'd say that I specifically disagree with
this section:

"""
Top-level namespace relates to code ownership
=============================================

This helps avoid clashes between project names.

Ownership could be:

* an individual.
[...]
* an organization.
[...]
* a group or community.
[...]
* a group or community related to another package.
"""

I'd say a top-level namespace should *never* (hello again, Barry!)
relate to an individual. And never to an organisation either, the
Django case notwithstanding. In the case of Django, I see the
top-level namespace as belonging to the *software* Django, not to the
*organisation*, the Django foundation. In fact, with the exception of
the "an individual" case, I'd say all of the others are actually
referring to the software rather than the organisation/group/community
owning that project.

To be honest, I see this whole section as misguided - the top-level
namespace is the project. Simple as that. Oh, and the terminology is
further muddled here, as the "top level namespace" is usually not a
namespace package in the sense of PEP 420.

Generally, the impression I get is that the PEP is recommending more
levels of nesting than I would agree with: But it's hard to be sure,
because the concept of nesting feels a bit overloaded. The key for me
is that generally, I like to be able to type "import X" where X is not
a dotted name, and then refer to X.x1, X.x2, etc. I'd call that no
levels of nesting, to be honest. For complex stuff, subpackages
("import X.Y") might be needed, but that's rare (and even then, key
names should be exposed directly from X).

Paul.

PS Having said all this, I don't maintain any code on PyPI - I'm a
user not a producer. That may affect my perspective...