[python-committers] deferred blockers

[Guido van Rossum]

On Sun, Sep 14, 2008 at 9:58 AM, "Martin v. Löwis" <martin at 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/)