On 5 June 2017 at 18:42, Cory Benfield <c...@lukasa.co.uk> wrote: > On 3 Jun 2017, at 07:25, Nick Coghlan <ncogh...@gmail.com> wrote: > As a result, as awkward and annoying as it would be, I'm wondering if > the structure of the requests migration may need to be something like: > > - switch unconditionally to an async backend on Py3 > - switch conditionally to an async backend on Py2 when PyOpenSSL is > available > - retain sufficient sync-only support on Py2 to allow pip to disable > the PyOpenSSL dependency > > Ultimately we don’t have the resources to do this. > > The requests core development team is 4 people, 3 of whom are part time > best-effort maintainers and one of whom is me, who has foolishly decided to > also work on PEP 543 as well as take over the lead maintenance role on > urllib3. urllib3 has another two additional best-effort maintainers. > > We simply do not have the development resources to support two parallel > branches of code. Even if we did, doing so is a recipe for adding bugs and > inconsistencies between the two, leading to increased workload as we break > our users and fail to keep the two branches in sync. It also makes it much > harder for users to migrate from our synchronous backend to our async one, > as those two no longer use identical underlying implementations and so will > have subtle inconsistencies. > > The TL;DR there is: no, we’d rather stay sync only than do that.
Would you be OK with the notion of a "just for pip bootstrapping" private backend in _ensurepip_ssl? That is, the only officially supported async-backed requests configuration on Py2 would be with the PyOpenSSL dependency installed, but in collaboration with the pip devs we'd also plumb in the pieces to let a new async-backed requests work without any extension modules other than those in the standard library. That way, the only thing truly gated on the backport would be *pip* updating its bundled version of requests to the async-backed version - for normal third party use, the change would be "you need PyOpenSSL", rather than "you need a newer version of Python". We'd still effectively end up with two different code execution paths (one backed by PyOpenSSL, one backed by the new private _ensurepip_ssl extension module), but the level of divergence would be much lower (it's just a question of where MemoryBIO and SSLObject are coming from) and the support scope for the less frequently used path would be much narrower (i.e. if a problem report isn't related to pip bootstrapping, it can be closed as "won't fix") Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
