[Python-Dev] Return type of round, floor, and ceil in 2.6

[Guido van Rossum]

On Jan 3, 2008 12:33 AM, Raymond Hettinger <python at rcn.com> wrote:
> > Consistency and compatibility with
> > 3.0 suggest that they should return long for every new type we add
> > them to. What does the list think?
>
> I think Py2.6 and Py2.5 should be treated with more respect.  Will backporting this change can only cause relief or create
> headaches?.   By definition, the Py3.0 release was supposed to be the one big incompatible set of changes.  Backporting with a goal
> of "consistency and compatibility with 3.0" suggests that the backporters may have lost their compass.

Whoa. Jeffrey is mostly backporting new stuff (such as numbers.py)
which doesn't introduce incompatibilities. The backporting is intended
to make 2.6 more attractive by allowing developers to do some of the
painful work of porting to 3.0 while staying on 2.6.

> FWIW, Py2.6 hasn't been released yet and no one *has* to upgrade to it.  So, if it is to have any chance of success, it needs to be
> a better Python than 2.5.  IMO, jamming 3.0 junk into 2.x just provides an incentive to skip the upgrade altogether.  In the press
> release for 2.6, we need to be able to say something stronger than:  filled with deprecations, two ways to do everything, dozens of
> tiny incompatibilities all done in the name of 3.0, and runs slower.

Watch your words, Raymond. I don't mind personally, but you run the
risk of discouraging contributors by slamming down on them with with
words like "jamming 3.0 junk into 2.x", and that's the last thing we
want to happen. We're thin on contributors as it is (have you noticed
how few people are submitting anything at all lately?).

2.6 should be extremely compatible with 2.5 by default. Its main
attraction should be that it is an important stepping stone in the
upgrade path from 2.{2,3,4,5} to 3.0 -- going straight from 2.5 to 3.0
will be much harder than going from 2.5 to 2.6, doing a bunch of work
while on 2.6, and then going to 3.0. The initial step from 2.5 to 2.6
should be very simple and painless.

There will still be plenty of good stuff in 2.6 to encourage folks to
upgrade who have no need for 3.0 (yet) -- this is the backported 3.0
stuff that doesn't create incompatibilities (like abc.py and
numbers.py).

> I think there ought to be a much more agressive standard for 3.0 backports:, "does the proposed backport make 2.6 more attractive?"
> Remember, for large code bases, upgrading is a PITA (I think Google is still running tons of code on 2.2, 2.3, and 2.4).  There
> needs to be a good incentive for upgrading; otherwise, Py2.6 *will* fail.

The incentive for upgrading will be "you can reach 3.0 easier via 2.6"
and perhaps "the latest version of 3rd party software X runs best on
2.6".

> The specific change suggested here is possibly (and perhaps probably) harmless; however, it is part of a larger trend that is not
> healthy for the 2.x series.

Where do you see evidence for a larger trend? I agree that a trend
towards making 2.6 less compatible with 2.5 would be a mistake, but I
don't think I see it happening.

Also, Facundo wrote:

> Well, as issue 1689 states, the backporting was commited by Jeffrey on
> rev 5967 [2], so this is the time to understand if we want this or
> not.

This is a problem. Right now, in the trunk, math.float(1) returns 1,
where it should return 1.0 for compatibility with 2.5. Jeffrey, can
you fix this and similar incompatibilities you introduced?

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