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

[Terry Reedy]

On 6/9/2010 5:05 AM, Tarek Ziadé wrote:

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

I do not see that changing the 'no new features in micro (bugfix) 
releases' policy would solve Ian's problem at all. Suppose unittest2 
were sufficiently done in September to go into 3.2 as unittest. Suppose 
the policy were changed and unittest2 were also backported into 
(3.1.final) and 2.7.1. That still would not help Ian with respect to 
2.6, 2.5, 2.4, and however far back he wants to support. Since whatever 
solution he uses for 2.6- should also work for 2.7 (and 3.1) what is the 
use?

Perhaps the reason for the policy needs to be restated: if new features 
are introduced in every x.y.z release, then 'Python x.y' has no 
particular meaning. This *was* the case somewhat during Python 1 and 
early Python 2 days, when the choice between moving from x.y.z to either 
x.y.(z+1) and x.(y+1) was somewhat arbitrary. (The move from '1.6' to 
'2.0' rather than '1.7' was for legal reasons only. Python2 really began 
with 2.2)

The precipitating event for the new policy was the introduction of 
bool() and prebound True and False late in 2.2 series. People who 
download the latest '2.2' release and who used the new feature found 
that their code would not run on the great majority of '2.2' 
installations. It caused enough problems for enough people that Guido 
decided that he should have waited for 2.3 for official introduction, 
and perhaps first released bool as a separate module for earlier use.

People who propose to change the policy back (are part way back) to what 
it used to be should at least be aware that it is a reversion and that 
there are reasons, and not just arbitrary whim or accidental 
happenstance, for the change.

Terry Jan Reedy