Hi!
Attached is a an updated proposal for PEP 423.
You can also find it online at https://gist.github.com/benoitbryon/2815051
I am attending at EuroPython 2013 in Florence. Isn't it a great
opportunity to get feedback and discuss about a PEP? I registered an
open-space session and a
In your first plone example you first use plone.app.content, but then present
the directory structure of plone.app.command.
Apart from that, the PEP seems legit to me, contentwise. I think some parts are
clumsily formulated, but IMO rewriting these parts wouldn't even decrease the
text's
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.
On 28 June 2012 11:36, Benoît Bryon ben...@marmelune.net wrote:
Also, I don't see what's so important about using
your company's name as a top-level namespace. You don't need it for
conflict avoidance: you can just as well use distinctive project names.
Using company's name as top-level
On Thu, 28 Jun 2012 12:35:24 +0200
Benoît Bryon ben...@marmelune.net wrote:
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
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
On 06/28/2012 06:36 AM, Benoît Bryon wrote:
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.
On Thu, 28 Jun 2012 08:14:07 -0400, Chris McDonough chr...@plope.com wrote:
It's probably always a reasonable idea to use a brand-prefixed namespace
for *private* packages but in my experience it's almost always a bad
idea to publish any set of otherwise-unrelated packages that share a
On Thu, 28 Jun 2012 12:53:47 +0200, =?ISO-8859-1?Q?Beno=EEt_Bryon?=
ben...@marmelune.net wrote:
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
Chris McDonough wrote:
People typically look for code on PyPI that solves a problem, and
branding in namespacing there is usually confusing. E.g. there are many
highly-general useful things in both the zope
When I search PyPI I ignore anything with djange, zope, etc., as I have
zero
On 6/28/2012 9:36 AM, Ethan Furman wrote:
When I search PyPI I ignore anything with djange, zope, etc., as I
have zero interest in pulling in a bunch of unrelated packages that I
don't need. If some of these pieces are truly stand-alone it would be
nice if they were presented that way.
+1
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 (we
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
Hello,
On Wed, 27 Jun 2012 11:08:45 +0200
Benoît Bryon ben...@marmelune.net wrote:
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?
There is one Zen principle this PEP is missing:
I thought the PEP actually covered it pretty well:
- if you don't want to worry about name conflicts for every module, pick
*one* short top level namespace for your group and use that
- for shared modules, use the top level namespace with PyPI as the name
registry
It's reasonable advice when
On Wed, 27 Jun 2012 21:19:57 +1000
Nick Coghlan ncogh...@gmail.com wrote:
I thought the PEP actually covered it pretty well:
- if you don't want to worry about name conflicts for every module, pick
*one* short top level namespace for your group and use that
- for shared modules, use the top
On 27 June 2012 12:34, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 27 Jun 2012 21:19:57 +1000
Nick Coghlan ncogh...@gmail.com wrote:
I thought the PEP actually covered it pretty well:
- if you don't want to worry about name conflicts for every module, pick
*one* short top level
On 27 June 2012 13:20, Paul Moore p.f.mo...@gmail.com wrote:
I agree. I only skimmed the PEP, but even on a skimming, I got the
impression that it was promoting the use of namespaces for ownership,
in a Java-like way. The part Nick quoted is substantially more
reasonable (assuming that's a
On 2012-06-27, at 10:57 AM, Paul Moore wrote:
Generally, the impression I get is that the PEP is recommending more
levels of nesting than I would agree with: But it's hard to be sure,
because the concept of nesting feels a bit overloaded. The key for me
is that generally, I like to be able to
On Wed, Jun 27, 2012 at 10:57 AM, Paul Moore p.f.mo...@gmail.com wrote:
For complex stuff, subpackages
(import X.Y) might be needed, but that's rare (and even then, key
names should be exposed directly from X).
Paul.
PS Having said all this, I don't maintain any code on PyPI - I'm a
user
21 matches
Mail list logo
