On Sun, Sep 14, 2008 at 9:58 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
You'll all be happy to know that we have no 2.6 deferred blockers. :)
I thought this was the plan from the beginning: make sure that for rc1, there aren't any blockers - not even deferred ones. All 3.0 blockers got deferred before 2.6rc1, but the 2.6 blockers stayed.
In case you wonder where they all went - I "resolved" a number of them by declaring that they shouldn't really block the release; in most cases, people then agreed (or didn't object).
Great -- thanks!
As a criterion, I asked "could that get fixed in 2.6.1 as well?", and I thought it could if
- it's not a regression wrt. 2.5, and
- it's not really that embarrassing, and
- fixing it won't violate the policies that we had established for bug fix releases.
It's the latter point I'd like to get more feedback on: for a few issues, I declared them as non-blockers because they dealt with the addition of -3 warnings, or lib2to3 additions.
I would claim that it is fine if both 2to3 fixers and -3 warnings get added to 2.6.1, even though they are strictly-speaking new features. For 2to3, it should be fairly obvious: most of the time, adding fixers just means that you have to do less work. There is a small chance, of course, that adding a fixer may break conversion for a code base for which conversion previously worked. Still, since conversion is mostly a manual process, developers invoking it will still be able to deal with that.
I would go further -- I don't see the fixers in 2to3 as part of the distribution in the same way as I see other library code. That is, in a sense I find it awkward that the fixers are all contained in the Lib tree -- this part of 2to3 feels like an application, not really a library, and clearly we should be doing all we can to improve the set of fixers over time! OTOH the APIs used to create fixers and to use lib2to3 for another purpose (e.g. for a hypothetical 3-to-2 converter or other transformations) should be considered as part of the standard library -- there's a lot of reusable code there!
For -3 warnings, I would also assume that people normally don't run Python with -3 (i.e. in production), but do so only if they actually look into porting to 3.0. Adding a warning will then let them find out problems more quickly which they would otherwise need to find out the hard way, so I also don't see how adding such warnings could cause problems.
This isn't so clear-cut as 2to3 fixers, but I think it is worthwhile to exempt -3 warnings from the "no new features" requirement, and instead to try to add more -3 warnings (and possibly remove or change existing ones) over time as we learn more about the subtleties of translating 2.6 code to 3.0.
Of course, if people disagree with these principles, it means that we either a) have those changes block 2.6 again, until they get resolved, or b) defer the change to 2.7. For 2to3 in particular, it would mean that the built-in version of 2to3 wouldn't change until 2.7 (except for clear bug fixes).
-- --Guido van Rossum (home page: http://www.python.org/~guido/)