[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