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

Paul Moore p.f.moore at gmail.com
Wed Jun 27 14:20:41 CEST 2012


On 27 June 2012 12:34, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 27 Jun 2012 21:19:57 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> I thought the PEP actually covered it pretty well:
>> - if you don't want to worry about name conflicts for every module, pick
>> *one* short top level namespace for your group and use that
>> - for shared modules, use the top level namespace with PyPI as the name
>> registry
>
> That's not very clear to me when reading the PEP.
> For example, one of the items in the "overview" is "use top-level
> namespace for ownership". I don't think it should be, unless we want to
> promote such a practice.

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.

I'd say that a headline item should be something like;

Using namespaces:
 - "Flat is better than nested" - where possible, use a single
top-level name for your package (check on PyPI that the name you
choose isn't in use).
 - Where you expect to have multiple packages all relating to the same
top-level functionality, it may make sense to use a single top-level
namespace package, and put your packages underneath that.
 - There should never be a need to use more than one level of
namespace (if you think there is, you should probably promote each of
the level-2 namespaces.to the top level).
 - Namespaces (and package names) should always be based on
functionality, never on ownership[1].

Personal or private code doesn't need to follow these guidelines, but
be aware that personal code often ends up more widely used than
originally envisaged...

[1] Sorry, Barry. There clearly needs to be an exception for the flufl
namespace :-)

Paul.


More information about the Python-Dev mailing list