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

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