Developers of the Python project have proposed (PEP 594) a significant cleanup of the standard library. The proposal suggests removing both explicitly deprecated and niche features from the standard library, as well as components that have architectural issues and cannot be unified across all platforms.
For example, it is suggested to exclude modules such as crypt (not available for Windows and dependence on system libraries for hashing algorithms), cgi (suboptimal architecture that requires launching a new process for each request), imp (importlib is recommended), pipes (subprocess module is recommended), nis (NSS, LDAP, or Kerberos/GSSAPI are recommended), spwd (direct database interaction with account databases is not recommended). Modules such as 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, in Python 3.8, the aforementioned modules will be marked as deprecated, warnings will begin to be issued in Python 3.8, and they will be removed from the CPython repositories in Python 3.10.
The parser module is planned for removal in version 3.9, as it was marked as deprecated in the Python 2.5 release, while the macpath module will be removed in branch 3.8. After removal from the main set, the code will be transferred to a separate legacylib repository, and its future will depend on the interest of community members. The Python 3.9 branch is expected to be supported until 2026, providing enough time to transition projects to external alternatives.
Initially, modules such as ftplib, optparse, getopt, colorsys, fileinput, lib2to3, and wave were also proposed for removal, but it was decided to keep them in the standard library for now, as they are widely used and remain relevant despite having more advanced alternatives or being tied to specific operating system features.
Recall that the Python project initially employs the approach of "batteries included," where the standard library offers an extensive set of functions for various application areas. The advantages of this approach include simplifying project maintenance in Python and monitoring the security of the modules used within projects. Vulnerabilities in modules often become sources of weaknesses in the applications that use them. If functions are part of the standard library, it's sufficient to control the state of the main project. When the standard library is split, developers need to use third-party modules, each of which must be monitored for vulnerabilities separately. A high degree of fragmentation and a large number of dependencies pose 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 for maintenance. The library has accumulated a large number of duplicative and unnecessary functions, and excluding them could reduce maintenance costs. As the catalog evolves, and the process of installing and downloading additional packages simplifies, using external modules has become as commonplace as built-in functions.
An increasing number of developers are using more functional external replacements for standard modules, such as using the lxml module instead of xml. Removing deprecated modules from the standard library will increase the popularity of actively developed community alternatives. Additionally, reducing the standard library will lead to a smaller base distribution size, which is important when using Python on embedded platforms with limited storage size.
Source: opennet.ru
