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