[Python-Dev] Thoughts on stdlib evolvement

[Ron Adam]

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