Why is Python 3 not backwards compatible?


I have learned that Python 3 is not backwards compatible.

Will it not affect a lot of applications using older versions of Python?

How did the developers of Python 3 not think it was absolutely necessary to make it backwards compatible?

Asked By: neelmeg



Is Python 3.0 backward-compatible and why?

Python 3.0 implements a lot of very useful features and breaks backward compatibility. It does it on purpose, so the great features can be implemented even despite the fact Python 2.x code may not work correctly under Python 3.x.

So, basically, Python 3.0 is not backward-compatible on purpose. Thanks to that, you can benefit from a whole new set of features. It is even called “Python 3000” or “Python 3K“.

From “What’s new in Python 3.0” (available here):

Python 3.0, compared to 2.6. Python 3.0, also known as “Python 3000” or “Py3K”, is the first ever intentionally backwards incompatible Python release. There are more changes than in a typical release, and more that are important for all Python users. Nevertheless, after digesting the changes, you’ll find that Python really hasn’t changed all that much – by and large, we’re mostly fixing well-known annoyances and warts, and removing a lot of old cruft.

Python features new in 3.0, breaking backward compatibility

Some of the most notable features that may be considered as breaking backward compatibility, but improving the language at the same time, are:

  • print is now a function, not a statement, and using it as statement will result in an error,
  • various functions & methods now return an iterator or view instead of list, which makes iterating through their results more memory-efficient (you do not need to store the whole list of results in the memory),
  • cmp argument for sorting functions like sorted() and list.sort() is no longer supported, and should be replaced by key argument,
  • int is now the same as Python 2.x’s long, which makes number processing less complex,
  • / operator is now an operator for true division by default (you can still use // for floor division),
  • text in Python 3.x is now Unicode by default,
  • True, False and None are now reserved words (so you are not able to do True, False = False, True,
  • changed usage of metaclass,
  • exceptions are required to be derived from BaseException, must be raised & caught differently than in Python 2.x,
  • and a lot more other changes, making Python more readable, consistent & explicit,
Answered By: Tadeck