(original) (raw)
On 3 Jun 2017, at 07:25, Nick Coghlan <ncoghlan@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.
Cory