Hi, thanks for the work on this proposal, I think this is at least a tip of
the iceberg and a good start for the bigger question of how the stdlib
should evolve..
I think that the PEP should include an idea of what should happen if
existing stdlib pieces depend on this deprecated modules. For example,
email.mime.audio is part of a non-deprecated module but it depends on
sndhdr which is being planned for deprecation. Should that part of the
functionality be deprecated too? rewritten to not depend on the deprecated
module (but keep the pieces of relevant code? depend on optional 3rd party
modules and degrade if those are not available?
The sndhdr case is just an example but I can imagine there are others
(optparse is no longer schedule for removal in your PEP, but would have
been another case, being used by the profile module).
Best,
Daniel
On Tue, 21 May 2019 at 15:15, Christian Heimes <christ...@python.org> wrote:
> Hi,
>
> I have updated the PEP with feedback from discussions. The highlights are:
>
> * Deprecate parser module
> * Keep fileinput module
> * Elaborate why crypt and spwd are dangerous and bad
> * Improve sections for cgitb, colorsys, nntplib, and smtpd modules
> * The colorsys, crypt, imghdr, sndhdr, and spwd sections now list suitable
> substitutions.
> * Mention that socketserver is going to stay for http.server and
> xmlrpc.server
> * The future maintenance section now states that the deprecated modules
> may be adopted by Python community members.
>
> https://github.com/python/peps/compare/7799178a...2d536899?diff=unified#diff-ae358c21fa7968ee3b6c64479e051574
>
>
> I'll be traveling the next couple of days and will only have limited
> opportunities to respond on feedback.
>
> Christian
>
> -------------------------------------------------------------------
> PEP: 594
> Title: Removing dead batteries from the standard library
> Author: Christian Heimes <christ...@python.org>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 20-May-2019
> Post-History: 21-May-2019
>
>
> Abstract
> ========
>
> This PEP proposed a list of standard library modules to be removed from the
> standard library. The modules are mostly historic data formats and APIs
> that
> have been superseded a long time ago, e.g. Mac OS 9 and Commodore.
>
>
> Rationale
> =========
>
> Back in the early days of Python, the interpreter came with a large set of
> useful modules. This was often refrained to as "batteries included"
> philosophy and was one of the corner stones to Python's success story.
> Users didn't have to figure out how to download and install separate
> packages in order to write a simple web server or parse email.
>
> Times have changed. The introduction of the cheese shop (PyPI), setuptools,
> and later pip, it became simple and straight forward to download and
> install
> packages. Nowadays Python has a rich and vibrant ecosystem of third party
> packages. It's pretty much standard to either install packages from PyPI or
> use one of the many Python or Linux distributions.
>
> On the other hand, Python's standard library is piling up cruft,
> unnecessary
> duplication of functionality, and dispensable features. This is undesirable
> for several reasons.
>
> * Any additional module increases the maintenance cost for the Python core
> development team. The team has limited resources, reduced maintenance
> cost
> frees development time for other improvements.
> * Modules in the standard library are generally favored and seen as the
> de-facto solution for a problem. A majority of users only pick 3rd party
> modules to replace a stdlib module, when they have a compelling reason,
> e.g.
> lxml instead of `xml`. The removal of an unmaintained stdlib module
> increases the chances of a community contributed module to become widely
> used.
> * A lean and mean standard library benefits platforms with limited
> resources
> like devices with just a few hundred kilobyte of storage (e.g. BBC
> Micro:bit). Python on mobile platforms like BeeWare or WebAssembly
> (e.g. pyodide) also benefit from reduced download size.
>
> The modules in the PEP have been selected for deprecation because their
> removal is either least controversial or most beneficial. For example
> least controversial are 30 years old multimedia formats like ``sunau``
> audio format, which was used on SPARC and NeXT workstations in the late
> 1980ties. The ``crypt`` module has fundamental flaws that are better solved
> outside the standard library.
>
> This PEP also designates some modules as not scheduled for removal. Some
> modules have been deprecated for several releases or seem unnecessary at
> first glance. However it is beneficial to keep the modules in the standard
> library, mostly for environments where installing a package from PyPI is
> not
> an option. This can be cooperate environments or class rooms where external
> code is not permitted without legal approval.
>
> * The usage of FTP is declining, but some files are still provided over
> the FTP protocol or hosters offer FTP to upload content. Therefore
> ``ftplib`` is going to stay.
> * The ``optparse`` and ``getopt`` module are widely used. They are mature
> modules with very low maintenance overhead.
> * According to David Beazley [5]_ the ``wave`` module is easy to teach to
> kids and can make crazy sounds. Making a computer generate crazy sounds
> is
> powerful and highly motivating exercise for a 9yo aspiring developer.
> It's
> a fun battery to keep.
>
>
> Deprecation schedule
> ====================
>
> 3.8
> ---
>
> This PEP targets Python 3.8. Version 3.8.0 final is scheduled to be
> released
> a few months before Python 2.7 will reach its end of lifetime. We expect
> that
> Python 3.8 will be targeted by users that migrate to Python 3 in 2019 and
> 2020. To reduce churn and to allow a smooth transition from Python 2,
> Python 3.8 will neither raise `DeprecationWarning` nor remove any
> modules that have been scheduled for removal. Instead deprecated modules
> will
> just be *documented* as deprecated. Optionally modules may emit a
> `PendingDeprecationWarning`.
>
> All deprecated modules will also undergo a feature freeze. No additional
> features should be added. Bug should still be fixed.
>
> 3.9
> ---
>
> Starting with Python 3.9, deprecated modules will start issuing
> `DeprecationWarning`. The `parser`_ module is removed and potentially
> replaced with a new module.
>
> All other deprecated modules are fully supported and will receive security
> updates until Python 3.9 reaches its end of lifetime. Python 3.9.0 will
> be released about 18 months after 3.8.0 (April 2021?) and most likely
> be supported for 5 years after the release. The estimated EOL of Python 3.9
> is in 2026.
>
> 3.10
> ----
>
> In 3.10 all deprecated modules will be removed from the CPython repository
> together with tests, documentation, and autoconf rules.
>
>
> PEP acceptance process
> ======================
>
> 3.8.0b1 is scheduled to be release shortly after the PEP is officially
> submitted. Since it's improbable that the PEP will pass all stages of the
> PEP process in time, I propose a two step acceptance process that is
> analogous Python's two release deprecation process.
>
> The first *provisionally accepted* phase targets Python 3.8.0b1. In the
> first
> phase no code is changes or removed. Modules are only documented as
> deprecated. The only exception is the `parser`_ module. It has been
> documented as deprecated since Python 2.5 and is scheduled for removal for
> 3.9 to make place for a more advanced parser.
>
> The final decision, which modules will be removed and how the removed code
> is preserved, can be delayed for another year.
>
>
> Deprecated modules
> ==================
>
> The modules are grouped as data encoding, multimedia, network, OS
> interface,
> and misc modules. The majority of modules are for old data formats or
> old APIs. Some others are rarely useful and have better replacements on
> PyPI, e.g. Pillow for image processing or NumPy-based projects to deal with
> audio processing.
>
> .. csv-table:: Table 1: Proposed modules deprecations
> :header: "Module", "Deprecated in", "To be removed", "Replacement"
> :widths: 1, 1, 1, 2
>
> aifc,3.8,3.10,\-
> asynchat,3.8,3.10,asyncio
> asyncore,3.8,3.10,asyncio
> audioop,3.8,3.10,\-
> binhex,3.8,3.10,\-
> cgi,3.8,3.10,\-
> cgitb,3.8,3.10,\-
> chunk,3.8,3.10,\-
> colorsys,3.8,3.10,"colormath, colour, colorspacious, Pillow"
> crypt,3.8,3.10,"bcrypt, argon2cffi, hashlib, passlib"
> fileinput,\-,**keep**,argparse
> formatter,3.4,3.10,\-
> fpectl,**3.7**,**3.7**,\-
> getopt,**3.2**,**keep**,"argparse, optparse"
> imghdr,3.8,3.10,"filetype, puremagic, python-magic"
> imp,**3.4**,3.10,importlib
> lib2to3,\-,**keep**,
> macpath,**3.7**,**3.8**,\-
> msilib,3.8,3.10,\-
> nntplib,3.8,3.10,\-
> nis,3.8,3.10,\-
> optparse,\-,**keep**,argparse
> ossaudiodev,3.8,3.10,\-
> parser,**2.5**,**3.9**,"ast, lib2to3.pgen2"
> pipes,3.8,3.10,subprocess
> smtpd,"**3.4.7**, **3.5.4**",3.10,aiosmtpd
> sndhdr,3.8,3.10,"filetype, puremagic, python-magic"
> spwd,3.8,3.10,"python-pam, simplepam"
> sunau,3.8,3.10,\-
> uu,3.8,3.10,\-
> wave,\-,**keep**,
> xdrlib,3.8,3.10,\-
>
>
> Data encoding modules
> ---------------------
>
> binhex
> ~~~~~~
>
> The `binhex <https://docs.python.org/3/library/binhex.html>`_ module
> encodes
> and decodes Apple Macintosh binhex4 data. It was originally developed for
> TSR-80. In the 1980s and early 1990s it was used on classic Mac OS 9 to
> encode binary email attachments.
>
> Module type
> pure Python
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> **none**
>
> uu
> ~~
>
> The `uu <https://docs.python.org/3/library/uu.html>`_ module provides
> uuencode format, an old binary encoding format for email from 1980. The uu
> format has been replaced by MIME. The uu codec is provided by the binascii
> module.
>
> Module type
> pure Python
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> **none**
>
> xdrlib
> ~~~~~~
>
> The `xdrlib <https://docs.python.org/3/library/xdrlib.html>`_ module
> supports
> the Sun External Data Representation Standard. XDR is an old binary
> serialization format from 1987. These days it's rarely used outside
> specialized domains like NFS.
>
> Module type
> pure Python
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> **none**
>
>
> Multimedia modules
> ------------------
>
> aifc
> ~~~~
>
> The `aifc <https://docs.python.org/3/library/aifc.html>`_ module provides
> support for reading and writing AIFF and AIFF-C files. The Audio
> Interchange
> File Format is an old audio format from 1988 based on Amiga IFF. It was
> most
> commonly used on the Apple Macintosh. These days only few specialized
> application use AIFF.
>
> Module type
> pure Python (depends on `audioop`_ C extension)
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> **none**
>
> audioop
> ~~~~~~~
>
> The `audioop <https://docs.python.org/3/library/audioop.html>`_ module
> contains helper functions to manipulate raw audio data and adaptive
> differential pulse-code modulated audio data. The module is implemented in
> C without any additional dependencies. The `aifc`_, `sunau`_, and `wave`_
> module depend on `audioop`_ for some operations. The byteswap operation in
> the `wave`_ module can be substituted with little work.
>
> Module type
> C extension
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> **none**
>
> colorsys
> ~~~~~~~~
>
> The `colorsys <https://docs.python.org/3/library/colorsys.html>`_ module
> defines color conversion functions between RGB, YIQ, HSL, and HSV
> coordinate
> systems.
>
> The PyPI packages *colormath*, *colour*, and *colorspacious* provide more
> and
> advanced features. The Pillow library is better suited to transform images
> between color systems.
>
> Module type
> pure Python
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> `colormath <https://pypi.org/project/colormath/>`_,
> `colour <https://pypi.org/project/colour/>`_
> `colorspacious <https://pypi.org/project/colorspacious/>`_,
> `Pillow <https://pypi.org/project/Pillow/>`_
>
> chunk
> ~~~~~
>
> The `chunk <https://docs.python.org/3/library/chunk.html>`_ module
> provides
> support for reading and writing Electronic Arts' Interchange File Format.
> IFF is an old audio file format originally introduced for Commodore and
> Amiga. The format is no longer relevant.
>
> Module type
> pure Python
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> **none**
>
> imghdr
> ~~~~~~
>
> The `imghdr <https://docs.python.org/3/library/imghdr.html>`_ module is a
> simple tool to guess the image file format from the first 32 bytes
> of a file or buffer. It supports only a limited amount of formats and
> neither returns resolution nor color depth.
>
> Module type
> pure Python
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> `puremagic <https://pypi.org/project/puremagic/>`_,
> `filetype <https://pypi.org/project/filetype/>`_,
> `python-magic <https://pypi.org/project/python-magic/>`_
>
> ossaudiodev
> ~~~~~~~~~~~
>
> The `ossaudiodev <https://docs.python.org/3/library/ossaudiodev.html>`_
> module provides support for Open Sound System, an interface to sound
> playback and capture devices. OSS was initially free software, but later
> support for newer sound devices and improvements were proprietary. Linux
> community abandoned OSS in favor of ALSA [1]_. Some operation systems like
> OpenBSD and NetBSD provide an incomplete [2]_ emulation of OSS.
>
> Module type
> C extension
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> **none**
>
> sndhdr
> ~~~~~~
>
> The `sndhdr <https://docs.python.org/3/library/sndhdr.html>`_ module is
> similar to the `imghdr`_ module but for audio formats. It guesses file
> format, channels, frame rate, and sample widths from the first 512 bytes of
> a file or buffer. The module only supports AU, AIFF, HCOM, VOC, WAV, and
> other ancient formats.
>
> Module type
> pure Python (depends on `audioop`_ C extension for some operations)
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> `puremagic <https://pypi.org/project/puremagic/>`_,
> `filetype <https://pypi.org/project/filetype/>`_,
> `python-magic <https://pypi.org/project/python-magic/>`_
>
> sunau
> ~~~~~
>
> The `sunau <https://docs.python.org/3/library/sunhdr.html>`_ module
> provides
> support for Sun AU sound format. It's yet another old, obsolete file
> format.
>
> Module type
> pure Python (depends on `audioop`_ C extension for some operations)
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> **none**
>
>
> Networking modules
> ------------------
>
> asynchat
> ~~~~~~~~
>
> The `asynchat <https://docs.python.org/3/library/asynchat.html>`_ module
> is build on top of `asyncore`_ and has been deprecated since Python 3.6.
>
> Module type
> pure Python
> Deprecated in
> 3.6
> Removed in
> 3.10
> Substitute
> asyncio
>
> asyncore
> ~~~~~~~~
>
> The `asyncore <https://docs.python.org/3/library/asyncore.html>`_ module
> was
> the first module for asynchronous socket service clients and servers. It
> has been replaced by asyncio and is deprecated since Python 3.6.
>
> The ``asyncore`` module is also used in stdlib tests. The tests for
> ``ftplib``, ``logging``, ``smptd``, ``smtplib``, and ``ssl`` are partly
> based on ``asyncore``. These tests must be updated to use asyncio or
> threading.
>
> Module type
> pure Python
> Deprecated in
> 3.6
> Removed in
> 3.10
> Substitute
> asyncio
>
>
> cgi
> ~~~
>
> The `cgi <https://docs.python.org/3/library/cgi.html>`_ module is a
> support
> module for Common Gateway Interface (CGI) scripts. CGI is deemed as
> inefficient because every incoming request is handled in a new process. PEP
> 206 considers the module as *designed poorly and are now near-impossible
> to fix*.
>
> Several people proposed to either keep the cgi module for features like
> `cgi.parse_qs()` or move `cgi.escape()` to a different module. The
> functions `cgi.parse_qs` and `cgi.parse_qsl` have been
> deprecated for a while and are actually aliases for
> `urllib.parse.parse_qs` and `urllib.parse.parse_qsl`. The
> function `cgi.quote` has been deprecated in favor of `html.quote`
> with secure default values.
>
> Module type
> pure Python
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> **none**
>
>
> cgitb
> ~~~~~
>
> The `cgitb <https://docs.python.org/3/library/cgitb.html>`_ module is a
> helper for the cgi module for configurable tracebacks.
>
> The ``cgitb`` module is not used by any major Python web framework (Django,
> Pyramid, Plone, Flask, CherryPy, or Bottle). Only Paste uses it in an
> optional debugging middleware.
>
> Module type
> pure Python
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> **none**
>
> smtpd
> ~~~~~
>
> The `smtpd <https://docs.python.org/3/library/smtpd.html>`_ module
> provides
> a simple implementation of a SMTP mail server. The module documentation
> marks the module as deprecated and recommends ``aiosmtpd`` instead. The
> deprecation message was added in releases 3.4.7, 3.5.4, and 3.6.1.
>
> Module type
> pure Python
> Deprecated in
> **3.7**
> To be removed in
> 3.10
> Substitute
> aiosmtpd
>
> nntplib
> ~~~~~~~
>
> The `nntplib <https://docs.python.org/3/library/nntplib.html>`_ module
> implements the client side of the Network News Transfer Protocol (nntp).
> News
> groups used to be a dominant platform for online discussions. Over the last
> two decades, news has been slowly but steadily replaced with mailing lists
> and web-based discussion platforms. Twisted is also
> `planning <https://twistedmatrix.com/trac/ticket/9405>`_ to deprecate NNTP
> support and `pynnt <https://github.com/greenbender/pynntp>`_ hasn't seen
> any
> activity since 2014. This is a good indicator that the public interest in
> NNTP support is declining.
>
> The ``nntplib`` tests have been the cause of additional work in the recent
> past. Python only contains client side of NNTP. The tests connect to
> external news server. The servers are sometimes unavailble, too slow, or do
> not work correctly over IPv6. The situation causes flaky test runs on
> buildbots.
>
> Module type
> pure Python
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> **none**
>
>
> Operating system interface
> --------------------------
>
> crypt
> ~~~~~
>
> The `crypt <https://docs.python.org/3/library/crypt.html>`_ module
> implements
> password hashing based on ``crypt(3)`` function from ``libcrypt`` or
> ``libxcrypt`` on Unix-like platform. The algorithms are mostly old, of poor
> quality and insecure. Users are discouraged to use them.
>
> * The module is not available on Windows. Cross-platform application need
> an alternative implementation any way.
> * Only DES encryption is guarenteed to be available. DES has an extremely
> limited key space of 2**56.
> * MD5, salted SHA256, salted SHA512, and Blowfish are optional extension.
> SSHA256 and SSHA512 are glibc extensions. Blowfish (bcrypt) is the only
> algorithm that is still secure. However it's in glibc and therefore not
> commonly available on Linux.
> * Depending on the platform, the ``crypt`` module is not thread safe. Only
> implementations with ``crypt_r(3)`` are thread safe.
> * The module was never useful to interact with system user and password
> databases. On BSD, macOS, and Linux, all user authentication and
> password modification operations must go through PAM (pluggable
> authentication module), see `spwd`_ deprecation.
>
> Module type
> C extension + Python module
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> `bcrypt <https://pypi.org/project/bcrypt/>`_,
> `passlib <https://pypi.org/project/passlib/>`_,
> `argon2cffi <https://pypi.org/project/argon2-cffi/>`_,
> hashlib module (PBKDF2, scrypt)
>
> macpath
> ~~~~~~~
>
> The `macpath <https://docs.python.org/3/library/macpath.html>`_ module
> provides Mac OS 9 implementation of os.path routines. Mac OS 9 is no longer
> supported
>
> Module type
> pure Python
> Deprecated in
> 3.7
> Removed in
> 3.8
> Substitute
> **none**
>
> nis
> ~~~
>
> The `nis <https://docs.python.org/3/library/nis.html>`_ module provides
> NIS/YP support. Network Information Service / Yellow Pages is an old and
> deprecated directory service protocol developed by Sun Microsystems. It's
> designed successor NIS+ from 1992 never took off. For a long time, libc's
> Name Service Switch, LDAP, and Kerberos/GSSAPI are considered a more
> powerful
> and more secure replacement of NIS.
>
> Module type
> C extension
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> **none**
>
> spwd
> ~~~~
>
> The `spwd <https://docs.python.org/3/library/spwd.html>`_ module provides
> direct access to Unix shadow password database using non-standard APIs.
>
> In general it's a bad idea to use the spwd. The spwd circumvents system
> security policies, it does not use the PAM stack, and is only compatible
> with local user accounts, because it ignores NSS. The use of the ``spwd``
> module for access control must be consider a *security bug*, as it bypasses
> PAM's access control.
>
> Further more the ``spwd`` module uses the
> `shadow(3) <http://man7.org/linux/man-pages/man3/shadow.3.html>`_ APIs.
> Functions like ``getspnam(3)`` access the ``/etc/shadow`` file directly.
> This
> is dangerous and even forbidden for confined services on systems with a
> security engine like SELinux or AppArmor.
>
> Module type
> C extension
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> `python-pam <https://pypi.org/project/python-pam/>`_,
> `simpleplam <https://pypi.org/project/simplepam/>`_
>
> Misc modules
> ------------
>
> formatter
> ~~~~~~~~~
>
> The `formatter <https://docs.python.org/3/library/formatter.html>`_ module
> is an old text formatting module which has been deprecated since Python
> 3.4.
>
> Module type
> pure Python
> Deprecated in
> 3.4
> To be removed in
> 3.10
> Substitute
> *n/a*
>
> imp
> ~~~
>
> The `imp <https://docs.python.org/3/library/imp.html>`_ module is the
> predecessor of the
> `importlib <https://docs.python.org/3/library/importlib.html>`_ module.
> Most
> functions have been deprecated since Python 3.3 and the module since
> Python 3.4.
>
> Module type
> C extension
> Deprecated in
> 3.4
> To be removed in
> 3.10
> Substitute
> importlib
>
> msilib
> ~~~~~~
>
> The `msilib <https://docs.python.org/3/library/msilib.html>`_ package is a
> Windows-only package. It supports the creation of Microsoft Installers
> (MSI).
> The package also exposes additional APIs to create cabinet files (CAB). The
> module is used to facilitate distutils to create MSI installers with
> ``bdist_msi`` command. In the past it was used to create CPython's official
> Windows installer, too.
>
> Microsoft is slowly moving away from MSI in favor of Windows 10 Apps (AppX)
> as new deployment model [3]_.
>
> Module type
> C extension + Python code
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> **none**
>
> parser
> ~~~~~~
>
> The `parser <https://docs.python.org/3/library/parser.html>`_ module
> provides
> an interface to Python’s internal parser and byte-code compiler. The stdlib
> has superior ways to interact with the parse tree. From Python 2.5 onward,
> it's much more convenient to cut in at the Abstract Syntax Tree (AST)
> generation and compilation stage.
>
> The ``parser`` module causes additional work. It's C code that must be
> kept in sync with any change to Python's grammar and internal parser.
> Pablo wants to remove the parser module and promote lib2to3's pgen2 instead
> [6]_.
>
> Most importantly the presence of the ``parser`` module makes it harder to
> switch to something more powerful than a LL(1) parser [7]_. Since the
> ``parser`` module is documented as deprecated since Python 2.5 and a new
> parsing technology is planned for 3.9, the ``parser`` module is scheduled
> for
> removal in 3.9.
>
> Module type
> C extension
> Deprecated in
> 3.8, documented as deprecated since **2.5**
> To be removed in
> **3.9**
> Substitute
> ast, lib2to3.pgen2
>
> pipes
> ~~~~~
>
> The `pipes <https://docs.python.org/3/library/pipes.html>`_ module
> provides
> helpers to pipe the input of one command into the output of another
> command.
> The module is built on top of ``os.popen``. Users are encouraged to use
> the subprocess module instead.
>
> Module type
> pure Python
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> subprocess module
>
> Removed modules
> ===============
>
> fpectl
> ------
>
> The `fpectl <https://docs.python.org/3.6/library/fpectl.html>`_ module was
> never built by default, its usage was discouraged and considered dangerous.
> It also required a configure flag that caused an ABI incompatibility. The
> module was removed in 3.7 by Nathaniel J. Smith in
> `bpo-29137 <https://bugs.python.org/issue29137>`_.
>
> Module type
> C extension + CAPI
> Deprecated in
> 3.7
> Removed in
> 3.7
> Substitute
> **none**
>
>
> Modules to keep
> ===============
>
> Some modules were originally proposed for deprecation.
>
> fileinput
> ---------
>
> The `fileinput <https://docs.python.org/3/library/fileinput.html>`_ module
> implements a helpers to iterate over a list of files from ``sys.argv``. The
> module predates the optparser and argparser module. The same functionality
> can be implemented with the argparser module.
>
> Several core developers expressed their interest to keep the module in the
> standard library, as it is handy for quick scripts.
>
> Module type
> pure Python
>
> lib2to3
> -------
>
> The `lib2to3 <https://docs.python.org/3/library/2to3.html>`_ package
> provides
> the ``2to3`` command to transpile Python 2 code to Python 3 code.
>
> The package is useful for other tasks besides porting code from Python 2 to
> 3. For example `black`_ uses it for code reformatting.
>
> Module type
> pure Python
>
> getopt
> ------
>
> The `getopt <https://docs.python.org/3/library/getopt.html>`_ module
> mimics
> C's getopt() option parser.
>
> Although users are encouraged to use argparse instead, the getopt module is
> still widely used. The module is small, simple, and handy for C developers
> to write simple Python scripts.
>
> Module type
> pure Python
> Substitute
> argparse
>
> optparse
> --------
>
> The `optparse <https://docs.python.org/3/library/optparse.html>`_ module
> is
> the predecessor of the argparse module.
>
> Although it has been deprecated for many years, it's still too widely used
> to remove it.
>
> Module type
> pure Python
> Deprecated in
> 3.2
> Substitute
> argparse
>
> wave
> ----
>
> The `wave <https://docs.python.org/3/library/wave.html>`_ module provides
> support for the WAV sound format.
>
> The module is not deprecated, because The WAV format is still relevant
> these
> days. The ``wave`` module is also used in education, e.g. to show kids how
> to make noise with a computer.
>
> The module uses one simple function from the `audioop`_ module to perform
> byte swapping between little and big endian formats. Before 24 bit WAV
> support was added, byte swap used to be implemented with the ``array``
> module. To remove ``wave``'s dependency on the ``audioop``, the byte swap
> function could be either be moved to another module (e.g. ``operator``) or
> the ``array`` module could gain support for 24 bit (3 byte) arrays.
>
> Module type
> pure Python (depends on *byteswap* from `audioop`_ C extension)
> Deprecated in
> 3.8
> To be removed in
> 3.10
> Substitute
> *n/a*
>
>
> Future maintenance of removed modules
> =====================================
>
> The main goal of the PEP is to reduce the burden and workload on the Python
> core developer team. Therefore removed modules will not be maintained by
> the core team as separate PyPI packages. However the removed code, tests
> and
> documentation may be moved into a new git repository, so community members
> have a place from which they can pick up and fork code.
>
> A first draft of a `legacylib <https://github.com/tiran/legacylib>`_
> repository is available on my private Github account. The modules could be
> made available on PyPI. The Python core team will not publish or maintain
> the packages. It is my hope that members of the Python community will
> adopt, maintain, and perhaps improve the deprecated modules.
>
> It's my hope that some of the deprecated modules will be picked up and
> adopted by users that actually care about them. For example ``colorsys``
> and
> ``imghdr`` are useful modules, but have limited feature set. A fork of
> ``imghdr`` can add new features and support for more image formats, without
> being constrained by Python's release cycle.
>
> Most of the modules are in pure Python and can be easily packaged. Some
> depend on a simple C module, e.g. `audioop`_ and `crypt`_. Since `audioop`_
> does not depend on any external libraries, it can be shipped in as binary
> wheels with some effort. Other C modules can be replaced with ctypes or
> cffi.
> For example I created `legacycrypt <https://github.com/tiran/legacycrypt
> >`_
> with ``_crypt`` extension reimplemented with a few lines of ctypes code.
>
>
> Discussions
> ===========
>
> * Elana Hashman and Nick Coghlan suggested to keep the *getopt* module.
> * Berker Peksag proposed to deprecate and removed *msilib*.
> * Brett Cannon recommended to delay active deprecation warnings and removal
> of modules like *imp* until Python 3.10. Version 3.8 will be released
> shortly before Python 2 reaches end of lifetime. A delay reduced churn
> for
> users that migrate from Python 2 to 3.8.
> * Brett also came up with the idea to keep lib2to3. The package is useful
> for other purposes, e.g. `black <https://pypi.org/project/black/>`_ uses
> it to reformat Python code.
> * At one point, distutils was mentioned in the same sentence as this PEP.
> To avoid lengthy discussion and delay of the PEP, I decided against
> dealing
> with distutils. Deprecation of the distutils package will be handled by
> another PEP.
> * Multiple people (Gregory P. Smith, David Beazley, Nick Coghlan, ...)
> convinced me to keep the `wave`_ module. [4]_
> * Gregory P. Smith proposed to deprecate `nntplib`_. [4]_
> * Andrew Svetlov mentioned the ``socketserver`` module is questionable.
> However it's used to implement ``http.server`` and ``xmlrpc.server``. The
> stdlib doesn't have a replacement for the servers, yet.
>
>
> Update history
> ==============
>
> Update 1
> --------
>
> * Deprecate `parser`_ module
> * Keep `fileinput`_ module
> * Elaborate why `crypt`_ and `spwd`_ are dangerous and bad
> * Improve sections for `cgitb`_, `colorsys`_, `nntplib`_, and `smtpd`_
> modules
> * The `colorsys`_, `crypt`_, `imghdr`_, `sndhdr`_, and `spwd`_ sections now
> list suitable substitutions.
> * Mention that ``socketserver`` is going to stay for ``http.server`` and
> ``xmlrpc.server``
> * The future maintenance section now states that the deprecated modules
> may be adopted by Python community members.
>
> References
> ==========
>
> .. [1]
> https://en.wikipedia.org/wiki/Open_Sound_System#Free,_proprietary,_free
> .. [2] https://man.openbsd.org/ossaudio
> .. [3]
> https://blogs.msmvps.com/installsite/blog/2015/05/03/the-future-of-windows-installer-msi-in-the-light-of-windows-10-and-the-universal-windows-platform/
> .. [4] https://twitter.com/ChristianHeimes/status/1130257799475335169
> .. [5] https://twitter.com/dabeaz/status/1130278844479545351
> .. [6] https://mail.python.org/pipermail/python-dev/2019-May/157464.html
> .. [7]
> https://discuss.python.org/t/switch-pythons-parsing-tech-to-something-more-powerful-than-ll-1/379
>
>
> Copyright
> =========
>
> This document has been placed in the public domain.
>
>
>
> ..
> Local Variables:
> mode: indented-text
> indent-tabs-mode: nil
> sentence-end-double-space: t
> fill-column: 70
> coding: utf-8
> End:
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/dfmoisset%40gmail.com
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
