[Python-Dev] Python 4: don't remove anything, don't break backward compatibility (original) (raw)

Cameron Simpson cs at zip.com.au
Tue Mar 11 03:19:27 CET 2014

On 10Mar2014 14:55, Victor Stinner <victor.stinner at gmail.com> wrote:

Last 5 years, I spend significant time to port a lot of Python 2 code on Python 3. [... troubles ...] So can we please try to stop scheduling another major Python version breaking almost all modules and all applications just to be pendantic? No, we should not remove any old feature in Python 4. Python 4 should be just a minor release following the previous 3.x release.

Maybe that will be the case, when it rolls around in the ordinary sequence of things. Assuming nothing groundbreaks shows up.

I don't want another six, nine or whatever module to fill the gap between Python 3 and Python 4.

But this I do not understand. If 4.0 is in your vision to be a regular release, why should you care that it may be years off?

For example, I propose to release the next major Python version (3.5) with the version 4.0 but without removing anything. (It's just an example, it can wait another release.)

Just in case this is not a joke or hyperbole: I am -1 on this.

Just stick with the expected numbering scheme.

If there are no incompatible but desired changes queued up by the time 4.0, perhaps that will be a normal release also. If not, perhaps it will be a good time to bite the bullet.

I mean that any incompatible change must following the classic transition plan: tag the feature as deprecated and wait at least one major version before dropping it, or just keep it forever. We can expect that just changing the major version (3 => 4) will already break enough applications (where "python3" or "version == 3" is hardcoded")...

I tend to spell this >= 3, etc. Maybe I'm being simplistic.

Instead of asking application developers to try to follow each major Python release, we should try to keep the maintaince pain in Python core.

What do you think?

I agree there shouldn't be a major porting pain release just for the sake of a number change; anything like that should need justification. But conversely, I'm dead against bringing forward version 4.0 just to break the expectation of breakage.

Cheers,

Cameron Simpson <cs at zip.com.au>

The nice thing about standards is that you have so many to choose from; furthermore, if you do not like any of them, you can just wait for next year's model. - Andrew S. Tanenbaum

More information about the Python-Dev mailing list