[Python-Dev] PEP 423 : naming conventions and recipes related to packaging (original) (raw)

Glenn Linderman v+python at g.nevcal.com
Thu Jun 28 19:37:18 CEST 2012

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>

More information about the Python-Dev mailing list