Python project developers a proposal (PEP 594) for a major cleanup of the standard library. Both clearly outdated and highly specialized features are offered for removal from the Python standard library, as well as components that have architectural problems and cannot be unified for all platforms.
For example, it was proposed to exclude from the standard library such modules as crypt (unavailability for Windows and the dependence of the availability of hashing algorithms on system libraries), cgi (not the optimal architecture, a new process is required for each request), imp (it is recommended to use importlib), pipes ( it is recommended to use the subprocess module), nis (it is recommended to use NSS, LDAP or Kerberos/GSSAPI), spwd (it is not recommended to work directly with the account database). Modules binhex, uu, xdrlib,
aifc,
audioop,
chunk
imghdr,
ossaudiodev,
sndhdr,
sunau
asynchat,
asyncore,
cgitb,
smtpd
nntplib, macpath,
formatter, msilib and parser.
According to the proposed plan, the above modules are planned to be deprecated in Python 3.8, to start warning in Python 3.8, and to be removed from the CPython repositories in Python 3.10.
The parser module is planned to be removed in version 3.9, as it was deprecated in the Python 2.5 release, and the macpath module in the 3.8 branch. After being removed from the main composition, the code will be moved to a separate legacylib repository and its fate will depend on the interest of the community representatives. The Python 3.9 branch is expected to be supported until 2026, giving enough time for projects to transition to external alternatives.
The modules ftplib, optparse, getopt, colorsys, fileinput, lib2to3, and wave were also originally proposed for removal, but it was decided to leave them in the standard library for the time being, as they are widespread and remain relevant, despite the availability of better alternatives or binding to specific features of operating systems.
Recall that the original Python project adopted a "batteries included" approach, in which the standard library offers a rich set of functions for a variety of applications. Among the advantages of this approach is the simplification of maintaining projects in Python and monitoring the security of modules used in projects. Vulnerabilities in modules often become a source of vulnerabilities in applications that use them. If the functions are included in the standard library, it is enough to control the state of the main project. When splitting the standard library, developers need to use third-party modules, vulnerabilities in each of which must be controlled separately. With a high degree of fragmentation and a large number of dependencies, there is a threat of attacks through compromising the infrastructure of module developers.
On the other hand, each additional module in the standard library requires resources from the Python development team to maintain. The library has accumulated a large number of duplicate and redundant functions, eliminating which can reduce maintenance costs. As the directory evolves and simplifying the process of installing and downloading additional packages, the use of plug-ins has now become as commonplace as built-in functions.
Increasingly large developers are using more functional external replacements for standard modules, such as using the lxml module instead of xml. Removing derelict modules from the standard library will increase the popularity of alternatives actively developed by the community. In addition, reducing the standard library will reduce the size of the base distribution, which is important when using Python on embedded platforms with limited storage.
Source: opennet.ru