[Python-Dev] PEP 423 : naming conventions and recipes related to packaging

[Glenn Linderman]

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 Precisely.

If a user wishes to install packages into "who_made_it" or 
"where_did_it_come_from" namespaces, and has a version of Python that 
supports namespaces, it would probably be a good idea for installers to 
easily permit that.  Then, if there are naming conflicts among packages 
from different sources, and they wish to use more than one 
"mypackage"... one from PyPI and one (or 3) from github, they can decide 
to name them as

mypackage (hah, this one is from PyPI and they used it first)
github.mypackage (first one from github)
github_fred.mypackage (the one by fred from github)
github_mary.mypackage (the one by mary from github)

The may choose to rename mypackage as PyPI.mypackage and 
github.mypackage as github_billy.mypackage to help discriminate, now 
that they have a need to discriminate, but that should be their choice, 
change versus compatibility.

Happily, it is possible to do either of the following to keep code names 
shorter:

import github_fred.mypackage as mypackage

import github_fred.mypackage as fredpackage

Reading JAVA code with lots of fully qualified by organization name is 
thoroughly confusing... it is unambiguous where the code came from, but 
it is also distracting when trying to understand the code, with all 
these long names that are irrelevant to the logic of the code.

And, of course, "mypackage" may be a set of alternative implementations 
of similar functionality, or it may be completely different 
functionalities that happen to use the same name (just as in English, 
when one word can have multitple definitions).

Maybe the PEP would be more useful by having it define package metadata 
standards such as

mypackage.__organization__ = 'The company or group or individual that 
created this package'
mypackage.__obtained_from__ = 'The location from which this package was 
obtained'

The former would be supplied by the package author; the latter would be 
filled in by the repository publisher (which may or may not be the same 
as the __organization__), or be a requirement to upload to the 
repository, or something along that line, so you'd know where to start a 
search for an updated version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120628/b86ca4b1/attachment.html>