Address concerns from python-dev for PEP 546. (#278)
* Adress concerns from python-dev. * Add myself to authors.
This commit is contained in:
parent
cd84e206f5
commit
ba07230ce7
64
pep-0546.txt
64
pep-0546.txt
|
@ -3,6 +3,7 @@ Title: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
|
|||
Version: $Revision$
|
||||
Last-Modified: $Date$
|
||||
Author: Victor Stinner <victor.stinner@gmail.com>,
|
||||
Cory Benfield <cory@lukasa.co.uk>,
|
||||
Status: Draft
|
||||
Type: Standards Track
|
||||
Content-Type: text/x-rst
|
||||
|
@ -67,10 +68,18 @@ requests, pip and ensurepip
|
|||
---------------------------
|
||||
|
||||
There are plans afoot to look at moving Requests to a more event-loop-y
|
||||
model, and doing so basically mandates a MemoryBIO. In the absence of a
|
||||
Python 2.7 backport, Requests is required to basically use the same
|
||||
solution that Twisted currently does: namely, a mandatory dependency on
|
||||
`pyOpenSSL <https://pypi.python.org/pypi/pyOpenSSL>`_.
|
||||
model. The Requests team does not feel at this time it is possible to abandon
|
||||
support for Python 2.7, so doing so would require using either Twisted or
|
||||
Tornado, or writing their own asynchronous abstraction.
|
||||
|
||||
For asynchronous code, a MemoryBIO provides substantial advantages over using a
|
||||
wrapped socket. It reduces the amount of buffering that must be done, works on
|
||||
IOCP-based reactors as well as select/poll based ones, and also greatly
|
||||
simplifies the reactor and implementation code. For this reason, Requests is
|
||||
disinclined to use a wrapped-socket-based implementation. In the absence of a
|
||||
backport to Python 2.7, Requests is required to use the same solution that
|
||||
Twisted does: namely, a mandatory dependency on `pyOpenSSL
|
||||
<https://pypi.python.org/pypi/pyOpenSSL>`_.
|
||||
|
||||
The `pip <https://pip.pypa.io/>`_ program has to embed all its
|
||||
dependencies for practical reasons: namely, that it cannot rely on any other
|
||||
|
@ -87,6 +96,53 @@ bundling PyOpenSSL. Only backporting ``ssl.MemoryBIO`` and
|
|||
``ssl.SSLObject`` would avoid the need to embed pyOpenSSL, and would fix the
|
||||
bootstrap issue (python -> ensurepip -> pip -> requests -> MemoryBIO).
|
||||
|
||||
This situation is less problematic than the barrier to adoption of PEP 543, as
|
||||
naturally Requests does not have to move to an event loop model before it drops
|
||||
support for Python 2.7. However, it does make it painful for Requests (and pip)
|
||||
to embrace both asyncio and the ``async`` and ``await`` keywords for as long as
|
||||
it continues to support Python 2.
|
||||
|
||||
Other Benefits
|
||||
--------------
|
||||
|
||||
Adopting this PEP would have other smaller ecosystem benefits. For example,
|
||||
Twisted would be able to reduce its dependency on third-party C extensions.
|
||||
Additionally, the PyOpenSSL development team would like to sunset the module,
|
||||
and this backport would free them up to do so in a graceful manner without
|
||||
leaving their users in the lurch.
|
||||
|
||||
Each of these fringe benefits, while small, also provides value to the wider
|
||||
Python ecosystem.
|
||||
|
||||
|
||||
Concerns
|
||||
========
|
||||
|
||||
There are some concerns that people have about this backport.
|
||||
|
||||
What About Old Python 2?
|
||||
------------------------
|
||||
|
||||
A number of the Python 2 users in the world are not keeping pace with Python 2
|
||||
releases. This is most usually because they are using LTS releases that are not
|
||||
keeping pace with the minor releases of Python 2. These users would not be able
|
||||
to use the MemoryBIO, and so projects concerned with Python 2 compatibility may
|
||||
be unable to rely on the MemoryBIO being present on most of their user's
|
||||
systems.
|
||||
|
||||
This concern is reasonable. How critical it is depends on the likelihood of
|
||||
current users of Python 2 migrating to Python 3, or just trying to use the most
|
||||
recent Python 2 release. Put another way, at some point libraries will want to
|
||||
drop Python 2 support: the question is only whether a significant majority of
|
||||
their Python 2 users have moved to whatever Python 2 release contains this
|
||||
backport before they do so.
|
||||
|
||||
Ultimately, the authors of this PEP believe that the burden of this backport is
|
||||
sufficiently minimal to justify backporting despite this concern. If it turns
|
||||
out that migration to newer 2.7 releases is too slow, then the value of the
|
||||
work will be minimal, but if the migration to newer 2.7 releases is anything
|
||||
like reasonable then there will be substantial value gained.
|
||||
|
||||
|
||||
Changes
|
||||
=======
|
||||
|
|
Loading…
Reference in New Issue