[Python-Dev] Python 3.0.1

[Guido van Rossum]

> On Jan 29, 2009, at 6:31 AM, A.M. Kuchling wrote:
>> If we intend for 3.0 to be a 'beta release', or to weaken the 'no
>> features in micro releases' rule, then fine; but we have to be *really
>> clear about it*.  Are we?  (The 3.0 release page calls it
>> production-ready.)

On Thu, Jan 29, 2009 at 8:59 AM, Barry Warsaw <barry at python.org> wrote:
> I think it sets bad precedence to downgrade our confidence in the release.
>  Again, my position is that it's better to stick to the same development
> processes we've always used, fix the most egregious problems in 3.0.1 with
> no API changes, but spend most of our energy on a 3.1 release in 6 months.

I'd like to find a middle ground. We can all agree that the users of
3.0 are a small minority compared to the 2.x users. Therefore I think
we can bend the rules more than we have done for the recent 2.x
releases. Those rules weren't always there (anyone remember the
addition of bool, True and False to 2.2.1?). The rules were introduced
for the benefit of our most conservative users -- people who introduce
Python in an enterprise and don't want to find that they are forced to
upgrade in six months.

Frankly, I don't really believe the users for whom those rules were
created are using 3.0 yet. Instead, I expect there to be two types of
users: people in the educational business who don't have a lot of
bridges to burn and are eager to use the new features; and developers
of serious Python software (e.g. Twisted) who are trying to figure out
how to port their code to 3.0. The first group isn't affected by the
changes we're considering here (e.g. removing cmp or some obscure
functions from the operator module). The latter group *may* be
affected, simply because they may have some pre-3.0 code using old
features that (by accident) still works under 3.0.

On the one hand I understand that those folks want a stable target. On
the other hand I think they would prefer to find out sooner rather
than later they're using stuff they shouldn't be using any more. It's
a delicate balance for sure, and I certainly don't want to open the
floodgates here, or rebrand 3.1 as 3.0.1 or anything like that. But I
really don't believe that the strictest interpretation of "no new
features" will benefit us for 3.0.1. Perhaps we should decide when to
go back to a more strict interpretation of the rules based on the
uptake of Python 3 compared to Python 2.

I don't believe that we risk influencing that uptake by bending the
rules; the uptake will depend on the availability of ported 3rd party
packages and some performance gains. (I don't know enough about the C
reimplementation of io.py to tell whether it could be folded into 3.0
or will have to wait for 3.1.)

Finally, to those who claim that 2.6 is a mess because multiprocessing
wasn't perfectly stable at introduction: that's never been the
standard we've used for totally *new* features. It's always been okay
to add slightly immature features at a major release, as long as (a)
they don't break anything else, and (b) we can fix things in the next
release while maintaining backward compatibility.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)