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 length
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 lightning-
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
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 P
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 interest
On Thu, 28 Jun 2012 12:53:47 +0200, =?ISO-8859-1?Q?Beno=EEt_Bryon?=
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 become a freq
On Thu, 28 Jun 2012 08:14:07 -0400, Chris McDonough 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
> branded namespace
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.
inter
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
On Thu, 28 Jun 2012 12:35:24 +0200
Benoît Bryon 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 remember the p
On 28 June 2012 11:36, Benoît Bryon 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 namespace has been
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 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
On Wed, Jun 27, 2012 at 10:57 AM, Paul Moore 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 not a prod
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
On 27 June 2012 13:20, Paul Moore 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 direct quote, rathe
On 27 June 2012 12:34, Antoine Pitrou wrote:
> On Wed, 27 Jun 2012 21:19:57 +1000
> Nick Coghlan 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
On Wed, 27 Jun 2012 21:19:57 +1000
Nick Coghlan 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 level namespace w
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 coupl
Hello,
On Wed, 27 Jun 2012 11:08:45 +0200
Benoît Bryon 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:
Flat is better
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
21 matches
Mail list logo
