Thoughts on some stdlib modules

[Ron_Adam]

On Sun, 10 Apr 2005 13:18:01 +0200, "Fredrik Lundh"
<fredrik at pythonware.com> wrote:

>Kay Schluehr wrote:
>
>> I fear that Python 3.0 becomes some kind of vaporware in the Python
>> community that paralyzes all redesign efforts on the std-lib.

Even if Python 3.0 never materializes, The documented PEP may still
have an impact on further development of Python. So it might also be
referred to as PEP __future__ .  

Has there been any suggestion of a time line?  If there is a new
release every 18 months, v2.4 to v3.0 would be, 108 months?,  Or would
there be a jump from v2.5 or 2.6, to v3.0?

>that, combined with the old observation that CPython developers,
>when given a choice, prefer to write C code over Python code, is
>making the standard library a lot less useful than it could be.
>
>(if you look at recent releases, most standard lib additions are things
>that are fun for language tinkerers and people looking for many ways
>to write simple algorithms, but very little stuff that's useful for
>scripters
>and application builders.  a C implementation of _bisect.  hello?)

"Fun" things and demos could be put in an "extras". That might do a
lot to clean up the library so that the rest of it can be put in
better perspective.  Also looking at my python24 directory there is a
'tools' dir that probably could be put in the extra package as well.

>if I were in charge, I'd separate 90% of the standard library from the
>core distribution, made sure it ran on multiple implementions (at least
>the two latest CPython implementations, plus what's needed to make
>as much as possible available on the latest Jython and IronPython
>releases), bundled a number of carefully selected external libraries
>(without forcing developers to give up rights and loose control over
>maintenance), refactor the test suite so it could be used both to test
>the library and to see what parts worked properly on your platform,
>and make new releases (for testers and early adopters) available
>regularily.
>
></F>

Larger utility packages could be moved from the "stdlib" but still be
included as separate packages that can optionally be installed from
the python installer.  Idle, distutils, tcl/tk, .. ?

Probably a clearer definition of purpose for the different parts is
needed.  I haven't seen anything documented on that specifically.  Has
it been upto recently, 'more is better' as long as it doesn't break
anything?  With the emphasis on growing the language?

What would definitions of 'purpose' be for?
    '__builtin__'
    '__builtins__'
	packages:
    	'stdlib' ... 'stdlib23', 'stdlib24' # Versions?
        'extras'         # examples, demos, and fun stuff
		other packages included in the install
        packages available at 'pythonpacks.com' (possible?)

	seperately installed applications ?

Is it possible to get some sort of overview on extending python? Does
one already exist?

Cheers,
Ron