Reinhold Birkenfeld wrote: > Hello, > > I am currently having some thoughts about the standard library, with regard > to Python 2.5 and 3.0. Since I don't want to withhold them from you, here > are they ;) > > - 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.
I think putting the standard library in it's own package would be the first step. "std" has been mentioned a couple of times and I think its a good name for it. For backwards compatibility, maybe a "from __compatible__ import ver_2.x", or something similar, could be used as a way to allow future versions a bit more flexibility to change? Trying to move the modules in python/lib to python/packages/stdlib to see what would happen revealed the following files are required to be in python/lib to start the python shell without errors. copy_reg.py ntpath.py os.py site.py stat.py types.py These files are modules site.py imports. Maybe these should be builtins so that the shell could start without importing any modules? > - 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], I'm on the side of less in builtins and less in the standard library, and for having a central repository for developers to distribute their packages. A python updater that gets a list of installable packages to install or uninstall would be fantastic. ;-) Having less in the core distribution means smaller complete applications to install when py2exe is used. There also needs to be some assurance that the standard library has as few bugs in it as possible. The more that's added to it, the more work and testing to do that is needed. > - User interface: Tkinter may be "the" standard, but other Toolkits deserve > notice, notably wxPython and PyGtk, the latter of which might be even > easier to package. I think these fall into the category of optional "official" extension packages that could be included in the core installer, but are not part of the standard library package itself. They are packages that would be maintained separately from the core and have their own developers dedicated to maintaining them. The 'official', or other designator if appropriate, would mean that they are important packages that fulfill a need and efforts to make and keep them compatible with the current python release is made. An "official" package designation might be something that developers could strive for and proudly display on their website or resume. Some minimum standards would be needed... ie current with current version of python, fully functional, fulfilling a need, etc. A request and voting process of some sort where python-dev can award "officialdom" to package developers might be usefull for this. Just a few thoughts, Cheers, Ron _______________________________________________ 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