<html>

 <head>

  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">

 </head>

 <body bgcolor="#FFFFFF" text="#330033">

  <div class="moz-cite-prefix">On 6/28/2012 9:36 AM, Ethan Furman

   wrote:<br>

  </div>

  <blockquote cite="mid:4FEC8825.5030205@stoneleaf.us" type="cite">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.

  </blockquote>

  <br>

  +1 Precisely.<br>

  <br>

  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<br>

  <br>

  mypackage (hah, this one is from PyPI and they used it first)<br>

  github.mypackage (first one from github)<br>

  github_fred.mypackage (the one by fred from github)<br>

  github_mary.mypackage (the one by mary from github)<br>

  <br>

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

  <br>

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

  names shorter:<br>

  <br>

  import github_fred.mypackage as mypackage<br>

  <br>

  import github_fred.mypackage as fredpackage<br>

  <br>

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

  <br>

  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).<br>

  <br>

  Maybe the PEP would be more useful by having it define package

  metadata standards such as<br>

  <br>

  mypackage.__organization__ = 'The company or group or individual

  that created this package'<br>

  mypackage.__obtained_from__ = 'The location from which this package

  was obtained'<br>

  <br>

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

 </body>

</html>