[Python-3000] pimp; restructuring the standard library
Phillip J. Eby
pje at telecommunity.com
Thu Jun 28 18:41:30 CEST 2007
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
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
>* 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
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.
More information about the Python-3000