Benoît
PEP: 423
Title: Naming conventions and recipes related to packaging
Version: $Revision$
Last-Modified: $Date$
Author: Benoît Bryon
Discussions-To:
Status: Deferred
Type: Informational
Content-Type: text/x-rst
Created: 24-May-2012
Post-History: 5-Jul-2013
Abstract
This doc
Hi,
Here is an informational PEP proposal:
http://hg.python.org/peps/file/52767ab7e140/pep-0423.txt
Could you review it for style, consistency and content?
Additional notes:
* Original discussion posted to distutils-...@python.org
* started on May 2012 at
http://mail.python.org/piperma
Le 27/06/2012 13:34, Antoine Pitrou a écrit :
Similarly, I think the section about private projects ("Private
(including closed-source) projects use a namespace") should be removed.
It is not our duty to promote naming standards for private (i.e.
internal) projects.
The intention in the proposed
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
Le 27/06/2012 22:08, Yury Selivanov a écrit :
With python adoption (enterprise too) growing, we will inevitably
find out that one single namespace (PyPI) is not enough, and
name collisions will become a frequent headache.
An argument for top-level namespace is related to PyPI
as a central place
Let's try to summarize answers about top-level namespace with use cases
and examples... I hope I understood them well...
About "yes" or "no" meaning:
yes
It fits the (work-in-progress) convention. You would
recommend it.
no
You wouldn't recommend the naming pattern for *new*
projects (w
