Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about how Python removes the old version features to welcome the new features, which may not be well understood by many people. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something from this article.

On April 20, 2020, the last version of Python 2, 2.7.18, was released, which means that Python 2 is the real EOL (end of life), and an era has finally come to an end.

Python 2.0 was released in 2000, and now it is exactly half a year short of the 20th anniversary, and the first-generation version has lasted such a long time. Of these, version 2.7 was released after the launch of Python 3, and it has been 10 years since it was released in 2010.

In fact, Python has been around for 30 years, but the evolution of the version has been slow, and the latest release is only 3.8.2.

Compared with the next-door contestants who are a few years apart, C++ has developed to 20, Java has developed to 14, PHP to 7.4, the gap is wide.

However, it is not always a good thing that versions are released too often. While Python programmers complain that their Python 2 projects have not yet been upgraded to version 3, some JAVA programmers are still maintaining versions 6 and 7 projects. The bitterness of the version migration, everyone is the same to each other, fifty steps laugh a hundred steps.

It is almost normal for programming languages to have incompatible features across versions. In many cases, it is not that the past design is bug, just because the programming language is also a kind of "life", it will learn other languages, will also evolve itself, so there is metabolism.

It sometimes takes a long transition period to get rid of old incompatible versions or some backward designs. In order to facilitate the migration of programmers, core developers have formed some effective practices.

Taking Python as an example, I know that there are several strategies:

1. DeprecationWarning prompt

DeprecationWarning alerts occur when out-of-date classes or methods are used.

For example, importing ABC (Abstract Base Classes, that is, abstract base classes) from the collections module is out-of-date usage, and the following prompt appears:

DeprecationWarning: Using or importing the ABCs from 'collections' instead of from' collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working

From version 3. 3, the correct usage is from collections.abc import Iterable, until version 3. 9, the expiration prompt is canceled and an error occurs.

2. Rename the module and make it private.

In Python, variables that start with a single underscore "_" are agreed to be private. If a private variable is defined in one module, it should not theoretically be exported to other modules for use.

This naming method has also been extended to the standard module. For example, there was a thread module in the very early version of Python, and then in version 1.5.1, there was a more convenient threading module based on thread, which is also known as the module that implements multithreading.

In order to get rid of / block the old implementation, Python renamed the thread module to _ thread and agreed to be private, which is so flexible that ordinary programmers will not be aware of its existence, but ashes-level programmers can use it to achieve lower-level development.

3. Make a deprecated prompt in the document

It means the same thing as DeprecationWarning. The reason for listing it separately is that when I was planning this article, I happened to find a tip in the Python 3.8 document, and I couldn't help sharing it.

The documentation says that the @ asyncio.coroutine decorator no longer supports coroutines implemented based on the yield from generator and needs to be explicitly written as "asyc def".

This means that version 3.8 is a dividing line for the feature and will enter a smooth phase-out cycle.

The above three ways can be described as "getting rid of the old", which is done in the past version. Corresponding to them, it is necessary to "welcome the new" process, to face the future version.

Some experimental features are sometimes added to Python in the current version, which are expected to be fully implemented in future versions. And this, you need to point out some transitional tips for programmers.

For example, in the article "Python 3.9 performance optimization: faster built-in types such as list (), dict (), and range ()," I introduced the "vectorcall" protocol hidden in version 3.8, which will not really be implemented in version 3.9 (and does not rule out further expansion in the future).

In addition, there is a famous example: the concurrent.futures standard library introduced in version 3.2 (based on PEP-3148).

This is an asynchronous development library that integrates multi-thread and multi-process. "concurrent" refers to concurrency, and the concept of "concurrency" can include the implementation of multi-thread and multi-process.

Why add a "futures" under "concurrent"? PEP-3148 points out three reasons for this name, the last of which is the hope that existing concurrency-related libraries can be added and moved to the concurrent library in the future (in the future).

In other words, version 3.2 of concurrent.futures is an experimental design in preparation for a better concurrent library in the future. Although the final realization in the future may be different from what is envisioned in PEP, this design idea for long-term consideration in the future will bring some expectation and common belief to the whole community.

After reading the above, do you have any further understanding of how Python removes the old version features to welcome the new features? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.