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

[Cameron Simpson]

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