Paul Boddie wrote: > Tim Churches wrote: > > Would it be possible to rename "Cheese Shop" as "Bright Side of Life"? > > Well, you could replay the conversation I gave as an example elsewhere > to see if it sounds ridiculous or not, but what we've encountered here > is the problem of whether something should be given a distinctive > identity or a derivative identity. A long time ago, and possibly > continuing to this day, people complained about how nearly every Python > package, module or program had names starting or ending with "Py" - > announcing a module in a Python newsgroup and giving it a name starting > with "Py" seemed somewhat redundant, and there was always the issue of > not being able to scan long lists of packages comfortably, just like > with all the KDE application names that start with the letter K. > > But even without "the curse of Py", many people don't just choose > arbitrary names for their packages: it often makes sense to include > related technologies in the name (eg. XML, XSLT, ado, dav), or to use a > descriptive component, possibly in shortened form (eg. auth, bayes, > bio, Cal). Yes, a search will often bring forth the right resource > regardless of what it's called, but many people underestimate their own > searching skills and overestimate what other people can find via things > like Google. > > Of course, programs may downplay Python as the implementation > technology because the underlying technical details are mostly > irrelevant to end-users (eg. BitTorrent, b3, Eric, Glarf), but if we > look at distinctively named packages, we can see that they often > attempt to define their own identity distinct from Python (eg. > BeautifulSoup, Dabo, DejaVu, Django, Twisted, Zope), frequently because > they seek to be the primary point of reference for developers - > developing in Twisted or Zope is more specialised than just developing > things in Python. Some of the distinctively named package names employ > metaphors and/or cultural references that possibly make them more > memorable, but they don't necessarily make the names easy to guess. > > So should a service for finding Python packages have a distinct > identity? It is possible that a package index could be someone's > principal view of the Python world ("I go to Camelot to get... what is > it I get there?"), but the things that emerge from such a service > aren't just downloads that have little in common with each other. > Consequently, I don't think a descriptive name, derived from the name > of the technology, is sensibly avoided in this case. > > Paul
The problem I have with the cheese-shop is less a naming but a usability issue. In some commercial projects that involve Python I already integrated SQLite as a local database for storing and retrieving all kind of configuration data as well as session data, failure statistics etc. I also extended a Python console in order to send SQL commands directly using this syntax "$ select * from reports where...". I should mention that this kind of integration was one of the most acknowledged features by those who where Python sceptics. I wonder if creating a database client, integreting it with a Python console and shipping it with a Python setup would not leave behind all other solutions in the field? BTW I'm not only intererested in the functionality of a package but how well it performs how well it is tested etc. The packages checked into the cheese-shop obtain already a rough classification. If classification schemes become more usable it is likely that they could be extended. Kay -- http://mail.python.org/mailman/listinfo/python-list