Python is a rapidly evolving language, with a major release every year and a five-year lifetime for each major release.

Frequent annual updates and a relatively short life cycle mean that developers must consider a major Python release migration every two to three years. On the surface, 5 years seems not short, but for software development, the life cycle of a large and medium-sized project (development and maintenance) is much longer than 5 years. A project may be developed for more than half a year, then go online for trial and officially start commercial use within a year, followed by 3 years of maintenance/iteration. The last year is an urgent time to consider the end of the life cycle of the main Python release, which has basically been updated at least three times.

In the current software development situation, the best approach is to take a continuous iterative approach, with developers anchoring to the latest major release for daily learning, and then anchoring to the next major release for actual business development and the online environment, keeping the business code in sync with newer releases. In the past, the workload and risk brought by the leapfrog large version upgrade are often much higher than the former.

This is the status of Python Branches: Status of Python Branches

Python forward compatibility issues

Python such interpreted language than Java such a compiled language on the principle of the lack of strong ability of static checking code, a line before and after the incompatible business code may need to be carried out in moment can be exposed, and Java such a compiled language, can be generated at compile time error or warning, Java code (or Groov Y /Scala/Kotlin) is compiled into intermediate code called Bytecode, and the JVM runs Bytecode instead of executing running Java code, decoupling the underlying JVM from the upper Java code. So in the case of Java and Python, Backward compatibility in Java is much better than in Python. A program that is many years old can run directly on a newer JVM with little need for compilation or needs to be compiled but significant compatibility issues can be detected at compile time. By contrast, Python has already produced several iterations of major releases during this time, and an older Version of Python may have accumulated many outdated/deprecated features in the new Python environment, causing some compatibility issues.

Reliable migration of code to new versions

Python’s approach to reliable migration is mostly post-mortem type, meaning that you need to combine very simple static code checks, and then continuously check the runtime status of the code and do a good job of unit testing.

Runtime warning

Python itself comes with a very useful startup parameter called -w. You can use the -w parameter to run your code when moving from a previous version, which allows you to find out in time what features are deprecated/removed from the current version compared to previous versions. When your current code uses outdated features marked deprecated/removed in a new version, it will output timely warning messages to help you adjust your code.

-w Multiple levels can be set. -werror, for example, converts a warning compatibility problem into an error, forcing you to make code adjustments.

For example, the following program

import threading if __name__ == '__main__': Thread = threading.currentThread() print(thread.name)Copy the code

When we run with -w in Python 3.10, we see the following

PS C:\workspace\ test> Python -v Python 3.10.0 # -wdefault will only generate a warning but will not interrupt the code to run PS C:\workspace\ test> Python -Wdefault .\temp.py C:\workspace\viper\test\temp.py:4: DeprecationWarning: currentThread() is deprecated, Use current_thread() instead thread = threading.currentThread() MainThread # -werror Generates an error and interrupts the code, forcing you to adjust your code to match the current Python environment PS C:\workspace\viper\test> python -Werror .\temp.py Traceback (most recent call last): File "C:\workspace\viper\test\temp.py", line 4, in <module> thread = threading.currentThread() File "C:\INSTALL\Python3\lib\threading.py", line 1429, in currentThread warnings.warn('currentThread() is deprecated, use current_thread() instead', DeprecationWarning: currentThread() is deprecated, use current_thread() instead PS C:\workspace\viper\test>Copy the code

So we can see from the above example that with -w, when we migrate old code to a new Python environment, running first and then collecting compatibility issues at run time is an effective means of migration assurance. When you collect compatibility issues, you can make batch adjustments to repeatable outdated code.

Other supplementary means

  • Static code checking: You can use some of the usual static code checking tools to do some preliminary compatibility screening, which is a prior step and can detect some very obvious problems
  • Code unit testingIt is best to write test cases for each API and key functions, so as to ensure that most of the business code has been run after automated testing-WThe combination of operation parameters has the best effect