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