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

Benoît Bryon benoit at marmelune.net
Thu Jun 28 12:35:24 CEST 2012


Le 27/06/2012 12:50, Antoine Pitrou a écrit :
> There is one Zen principle this PEP is missing:
> Flat is better than nested.
>
> This PEP seems to promote the practice of having a top-level namespace
> denote ownership. I think it should do the reverse: promote
> meaningful top-level packages (e.g. "sphinx") as standard practice, and
> allow an exception for when a piece of software is part of a larger
> organizational body.

The PEP's intention is to tell what Nick described. Maybe
the words are not clear...


Notes about the order of items in the overview:

1. respect names registered on PyPI. This is a requirement.

2. adopt specific conventions if any, i.e. don't break the
    rules that already exist in existing projects. This
    convention makes the PEP backward compatible. It is the
    first rule because, for project-related contributions, the
    first action should be to read the documentation of the main
    project.

3. important thing is to avoid name collisions. This is a
    requirement for project names, and a strong recommendation
    for package/module names.

4. use a single name. This rule simplifies the action of choosing
    a name and brings consistency. If you already know how your
    package/module is imported in code, you can simply use it as
    project name.

5. then, we'd better make it easy to find and remember the project.
    This is a strong advice.

6. then, all the points above being considered, we'd better use
    flat names.

7. rules about syntax (PEP 8).

8. state about specific conventions, if any. This is the complement
    of point 2.

9. ask.


Would you appreciate a reordering?
Could be something like that:

1. adopt specific conventions if any.

2. avoid name collisions.

3. you'd better use flat names.

4. you'd better make it easy to find and remember the project.

5. you'd better use a single name and distribute only one
    package at a time

6. follow rules about syntax (PEP 8)

7. once you are done, state about specific choices, if any.
    This is the complement of point 1.

8. if in doubt, ask.


> (i.e., "Community-owned projects can avoid namespace packages" should
> be the first item in the PEP and renamed so that it appears common rule)

I guess we could move "shared projects can use a one-level
name" before guidelines related to private projects.


Benoit



More information about the Python-Dev mailing list