Le 29/06/2012 12:50, Piotr Ozarowski a écrit :
[Benoît Bryon, 2012-06-29]
Le 28/06/2012 14:15, Piotr Ozarowski a écrit :
[Benoît Bryon, 2012-06-27]
http://hg.python.org/peps/file/52767ab7e140/pep-0423.txt
I think PEP 386 (about versions) should be mentioned in "Relationship
with other PEPs" section.
Why? Right now, I can't see the relationship between
projects/packages/modules names and versions.
The PEP name is "Naming conventions and recipes related to packaging"
and version numbers are related to packaging (and naming) for sure.
Ok. Maybe the title of the PEP is not clear.
It is related to naming conventions only, and only in
packaging (i.e. projects, and distributed packages or
modules, not variables, function or class names).
Would "naming conventions related to packaging" be better?
How about PEP 396 (Module Version Numbers)?
How are version numbers related to naming?
About "Use a single name" section: sometimes one needs to add "python-"
or "py" prefix to project name (f.e. if the name is already used in
other programming languages and you cannot register it in your favourite
forge hosting service)... but please don't add the prefix also in namespace.
All these PyQts, pyudevs, pygames and pyopencls sound stupid to me (isn't
it obvious that when I do `import foo` in Python, "foo" is a *Python*
library?)
Do you mean:
* "pip install pyqt" => yes,
* "import pyqt" => no,
* "import qt" => yes?
right
Currently, if the project name is "pyqt", then the PEP
proposal recommends "pip install pyqt" and "import pyqt",
to make the name consistent. If one is not a good choice,
change both.
It is convention over configuration.
that's my point, PyQt guys cannot use Qt as project name, but
"qt" it a better name for this namespace, IMO
IMHO, a "py" prefix for package name would not be a problem
in this case. You are not importing Qt itself, but Python
bindings for Qt.
it's not "a problem", I just think PEP should not recommend such
prefixes
By now, I feel that the "py" prefix use case is not special enough to
reconsider or break the "use a single name" rule.
I would accept to "import pyqt" instead of "import qt".
But that's my own viewpoint. I understand you don't subscribe to it.
May someone else enter the discussion and give his opinion about this
point?
I mean, yes, it is obvious that when I do `import foo` in
Python, then "foo" is a *Python* library. But would the
reverse assertion be that if I see "import qt" in Python
code, then it is obvious that Qt itself is a Python library?
There's a "readline" package in Python's stdlib, does it imply readline
is something Python related or specific?
You are right. My bad :)
The name could have been "qtbindings", would have it been a
problem then? The "py" prefix has the advantage to be clear:
that's *Python* bindings for Qt. And it's a really short
prefix.
qtbindings, qtlib or other similar prefixes/suffixes should not be
recommended, IMHO
About ".contrib.": flask uses flask.ext.foo (namespace) and Flask-Foo
(project name) schema for Flask extensions - maybe it's worth mentioning
in this PEP as well.
Maybe it will be used in discussions or in examples, but
I suppose the PEP is not the place to list all project-specific
conventions. Currently the draft PEP tells: "search for
specific conventions in main project (Flask) documentation".
I just thought "foo.ext.bar" is a nice convention worth mentioning
(next to, not instead of "contrib" which is more general than "ext")
I agree that "foo.ext.bar" seems nice... but it uses 3
namespace levels. It breaks the "avoid deep nesting"
rule, which recommends not more than two levels.
So the PEP can't recommend this pattern, or we will also have
to reconsider the "avoid deep nesting" rule.
Notice that, from current feedback about the PEP, I understand
that the "avoid deep nesting" rule sounds more valuable than
the "standard pattern for contributions".
About naming pattern for contribs, the draft PEP proposes:
* to use "foocontrib.bar" by default
* if there is a need to separate "extensions" from "contributions"
(supposing the difference is clearly documented), the project
can tell his users to:
* publish contributions in foocontrib.*
* publish extensions in fooext.*
That said, in that particular case, I would publish everything
related to foo (except foo itself) in the same namespace
(i.e. only foocontrib.*) and use metadata to categorize projects.
As an example, with something like keywords="foo extension".
So that:
* there is only one namespace package
* everything that is "related to foo" is under foocontrib.*
* if the "contribution" VS "extension" terminology change,
there is no need to move projects from one namespace to
another.
* a project can be both an extension and a contribution.
* it's possible to filter the list of packages at PyPI to
get the list of extensions: name starts with "foocontrib."
and has keyword "extension".
Benoit
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
