[Python-Dev] PEP 423 : naming conventions and recipes related to packaging (original) (raw)

Paul Moore p.f.moore at gmail.com
Wed Jun 27 16:57:56 CEST 2012

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:

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

More information about the Python-Dev mailing list