[Python-Dev] PEP 423 : naming conventions and recipes related to packaging
R. David Murray
rdmurray at bitdance.com
Thu Jun 28 15:47:23 CEST 2012
On Thu, 28 Jun 2012 08:14:07 -0400, Chris McDonough <chrism at 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
> branded namespace prefix to PyPI.
>
> I know this because I've been involved with it at least twice with
> "zope." and "repoze." brands/namespaces. The meaning of both of those
> namespaces has become soft over time and both now mean basically "this
> code was created by a group of people" instead of "this code is useful
> under a circumstance or for a purpose". Those namespaces are both the
> moral equivalent of a "garbage barge" class in development: code related
> to the namespace might do anything ("zope" now means a company and two
> completely different application servers; "repoze" never really meant
> anything, it was always a pure brand).
>
> 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. and repoze. namespace
> packages, but people are skittish about the meaning of the namespaces
> and tend to look for a "more generic" solution. They are often right to
Looking at Zope mostly from the outside (I was involved with zope
development during an early stage of zope 3, but I haven't been involved
or used it for years), this matches my perception as well. The zope
namespace made some sense early on, but as the project got refactored
into more cleanly separated pieces, it ends up just getting in the way
of wider adoption of the most useful pieces.
For what it is worth, notice that perl does not use organization names,
it uses functional names.
Which languages other than Java use organizational names?
--David
More information about the Python-Dev
mailing list