[Python-ideas] Moving development out of the standard library
tjreedy at udel.edu
Wed Jun 9 20:59:45 CEST 2010
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
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
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
More information about the Python-ideas