[Python-ideas] Moving development out of the standard library

[Tarek Ziadé]

On Wed, Jun 9, 2010 at 10:25 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
[..]
>
> I really don't understand where the big benefits are to having minor
> improvements introduced in bugfix releases.

To try to find a solution to the problems described in this thread earlier.

If I summarize so far the threads as I understood them, people don't
want to rely
on stdlib packages because their release cycles are too slow for what
they want/need to do with it *today*. A package that enters the stdlib
suffers from being slowed down. That's also a huge benefit for many reasons:
stability, blessing, etc.

The initial reason is that Ian doesn't want Pip do depend on distutils2 if
it's in the stdlib, because he will have to cope with various versions
of Python to make sure his users will have the same set of features I guess.

So he needs to provide his own backports of any new distutils2 features.

If we can find a way to facilitate this work, that would be great. IOW, if
we can provide somehow a backport of these features so some projects
can use it no matter what the python version is...

And "not putting distutils2 in the stdlib" is not the solution because
this is a problem
for all packages in there.

That's exactly what unitest currently do (but with a new name "unittest2")
and as soon as Python 2.7 final will be out, unittest will have the
same problem:
it won't be able to backport new features anymore under the same namespace.


[..]
> "No behavior changes in micro releases" is an easily understood,
> reasonably easily followed policy.  The policy you propose requires
> judgment calls that will differ from module maintainer to module
> maintainer, and every upgrade will involve discussion on python-dev.
> Yuck.

This idea I have was kind of rejected earlier in Python-ideas, if you
read back the
two/three latest threads on the topic. I have reintroduced here because
someone proposed to allow overriding stdlib packages. If this was to happen,
I'd rather have upgrades decided in python-dev than arbitrary ones.
But yes, that's too much burden...

Maybe the status quo would is the best idea :)

Regards
Tarek