On Thu, 28 Jun 2012 08:14:07 -0400, Chris McDonough
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