[Python-3000] pimp; restructuring the standard library

[tav]

> 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.

Ah, wasn't suggesting dumping the unittest module. Just that tests in
the "standard library" should be doctest-based as these are much nicer
and more useful!

> 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.

I agree with your -1.

Let me rephrase that as being able to use any character in a str for
import as opposed to the current limited set in 2.x. I understand that
python literals are much broader in 3.0, how does that impact import?

> >* 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?"  :)

Well, all that code being added to PyPi and the ASPN Python cookbook
ain't being done by imagination alone... ;p

Seriously, with:

a). clear 'lead by example' initial set of how modules should work
(with the above mentioned feature sets)

b). a provisional incentive model (say, via a gift economy model for
all those who have contributed to the standard library)

c). a simple hook in the importer which keeps track of modules/code is
used, which is used to remunerate the army (if anyone ever contributes
financially to it) ;p

> 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 understood that issues relating to the standard library were still
not fixed-in-stone for python 3.0?

> 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.

This is definitely true. But I want to see all this in Python 3.0...

And, I don't see any of the changes proposed requiring any changes to
the language.. besides the __subclasses__ and func_closure thing we
discussed on python-dev.

-- 
love, tav
founder and ceo, esp metanational llp

plex:espians/tav | tav at espians.com | +44 (0) 7809 569 369