[Python-3000] pimp; restructuring the standard library

[Phillip J. Eby]

At 04:59 PM 6/28/2007 +0100, tav wrote:
>* Abandoning of unit tests and replacing with full doctest coverage in
>the style perfected by Jim Fulton and PJE. Integration with py.test.

I believe that the origination credit for this rightly falls to Tim 
Peters.  (I just copied Jim, myself.)  Meanwhile, there are quite a 
few stdlib doctests now, and unittests still more than have their place.

Indeed, I'm also wary of breaking backward compatibility of unittest 
or doctest in Python 3.0, because that will make it even harder to 
port code over.  How will 2.x users run their existing test suites to 
verify their code has been ported correctly, if they can't keep using 
unittest?  As it is, they'll have to run them through 2to3, which 
AFAIK doesn't do doctests currently.


>* Ability to import from remote networked sources, e.g. import
>http://foo.com/blah/

A strong -1 on any import system that breaks down the current strict 
separation between module names and module *locations*.  Too many 
people confuse these concepts already, and we already have a nicely 
field-tested mechanism for specifying locations and turning them into 
importer objects.


>* Authentication of sources with configurable crypto.
>
>* Full integration with setuptools + eggs.
>
>* Pluggable integration support for version control systems like svn/bzr.
>
>* Builtin versioning support for modules.
>
>* Live-update of modules/code support (in the vein of Erlang).
>
>* Rewrite of standard library to be more adaptable, concurrent, and
>pertaining to object capability. This way, we can have a secure,
>composable and parallelisable standard library!

Um, and who are you volunteering to do all this work?  i.e., "you and 
what army?"  :)


>Hope this all makes some kind of sense... your thoughts will be much
>appreciated. Thanks!

My thought is that you've just proposed several major PEPs that are 
already too late for Python 3.0 and would probably have been rejected 
or deferred anyway.

I also think it's more likely that your ideas would find more 
interest/support with the PyPy project than with mainline Python, as 
some of them at least vaguely resemble some things they are working 
on, and/or would be easier to implement using PyPy object spaces.