Skip Montanaro wrote: > Tim> On 6/6/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: > > >> - Flat namespace: Should we tend to a more hierarchic library (e.g. > >> inet.url, inet.http, inet.nntp)? This would increase clarity when > >> searching for a module. > > Tim> -1. I feel the opposite way: when trying to figure out where > Tim> something "lives", I prefer Python's flat namespace to (for > Tim> example) Java's com.company.baz.bar.foo hierarchy. > > I think Reinhold's suggestion (e.g., inet.*) was for a flatter namespace > than Java's scheme, but for a slightly more structured namespace than the > current standard library provides. Some amount of structure helps to > collect modules together whose names don't obviously suggest who their > neighbors are in the functionality space. For example, to the naive user it > might not be obvious that these groups of modules and packages are related: > > * getopt and optparse > * bsddb, gdbm and anydbm > * email, mhlib, quopri > * heapq, collections > * user, site, sitecustomize > * profile, hotshot, pstats > * pipes, subprocess, os
Yep, exactly. Java's namespaces are ugly, that's right, but a flatter version certainly improves readability. """Namespaces are one honking great idea -- let's do more of those!""" > I wouldn't mind a stdlib that defined a set of top-level packages (some of > which might be wholly unpopulated by modules in the standard distribution) > It might, for example, define a gui package and gui.Tkinter and gui._tkinter > modules, leaving the remainder of gui namespace available for 3rd party > modules. Such a scheme would probably work best if there was some fairly > lightweight registration/approval process in the community to avoid needless > collisions. For example, it might be a bit confusing if two organizations > began installing their packages in a subpackage named gui.widgets. An > unsuspecting person downloading an application that used one version of > gui.widgets into environment with the conflicting gui.widgets would run into > trouble. Is the CPAN namespace wide open? If I wanted to create a Perl > module to fit into the HTML namespace is there some procedure involved or is > it an example of squatters' rights? Personally, I think that CPAN is one of the greatest strengths of Perl. The language is a mess, and the quality of many modules is questionable, but it's incredibly easy to find a module for handling a special problem, and the namespaces are IMHO well thought out. Additionally, the docs > >> - 3rd party modules: There are many superb modules out there, some of > >> which really do have a "standard" character. Examples include PIL, > >> numarray, ElementTree, [wxPython - I know this is a hairy issue], > > Tim> I think the most important question for each of these is "is the > Tim> module's release schedule at least as stable as Python's?". For > Tim> many of these, I suspect the answer is "no". > > If you provide the necessary namespace structure for them to nestle into, I > suspect most of them could be maintained outside the stdlib just fine. Exactly! There needn't be such a big separation between stdlib and 3rd party. Access to the net is standard nowadays, though it wouldn't be of any harm making a big distribution with all modules available, for downloading and burning on CD, for example. PJE's great EasyInstall and Python Eggs will be a perfect starting point for this, I think. Reinhold -- Mail address is perfectly valid! _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
