Re: Fwd: Re: Proposal and questions about PEP 420

On Sun, May 13, 2012 at 9:18 AM, Benoît Bryon <[email protected]> wrote:

> "Eric V. Smith" <[email protected]> wrote:
>
> > Hi, Benoit.
>
> > This hasn't been specifically discussed. Part of the rejection of PEP
> > 382 was due to dots in the names of directories, but as directory
> > extensions (foo.pyp). I'm not sure if this concern would also apply to
> > your proposal.
>
> > Also, I'm not sure how common nested namespace packages are. I know I've
> > never run across them.
>

zope.app and peak.util are two I know of.  But deep nesting isn't common in
the Python world, despite the popularity of things like
org.apache.someproject.gizmos.GizmoFactory in the Java world.

The proposal itself is intriguing, but it's not only less backward
compatible and directory-cluttering, it has some potential for ambiguity in
the spec and doesn't seem like a reasonable departure from other languages'
conventions in this area.

Regarding the nesting issue and persuading Django developers to use
namespaces, I would note that there isn't any reason for namespaces to be
deeply nested in the first place.  By convention, top-level namespace
packages should be the name of a project or its sponsoring organization,
which means there is rarely a need for deep nesting.  Even cases like
zope.app and peak.util are rare: usually a project or organization will
have only one such "miscellaneous" namespace with lots of
separately-distibuted components.

(After all, the main reason to *have* a namespace package is to have
separately-distributed subpackages.  So, self-contained packages don't need
to have namespaces of their own, almost by definition.)

Anyway, what I've noticed is that when people want to deeply nest
namespaces, it's usually because they're trying to share a namespace across
organizations, like making a shared 'net.*' namespace.  The idea of
namespaces isn't for that kind of categorization, though, it's for
*ownership*.  If two developers are fighting over where to put something in
a category hierarchy, it's a sign that they need to be working in different
namespaces, with each developer staking a claim to a *top-level* package --
like OSAF's osaf.*, Zope Corporation's zc.* (vs. the community project's
zope.*), and so on.

When developers use namespaces for project/ownership distinction, the
resulting package hierarchies can be pretty much as flat as you like.

_______________________________________________
Import-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/import-sig