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

[Victor Stinner]

Hi,

Last 5 years, I spend significant time to port a lot of Python 2 code
on Python 3. First, using the 2to3 tool + extra manual patches. Sorry,
it was not usable in practice. The conversion was very slow, it didn't
fix doctests nor all other minor "details". "Fixing Python 2 code" was
no always possible. I now use the six module (or a smaller subset) to
port applications to Python 3. Today, they are still many dependencies
blocking applications to be ported to Python 3.

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.

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

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.) 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")...

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?

Victor