[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
cory at lukasa.co.uk
Thu Jun 1 09:37:55 EDT 2017
> On 1 Jun 2017, at 14:21, Antoine Pitrou <antoine at python.org> wrote:
> Le 01/06/2017 à 15:12, Cory Benfield a écrit :
>> I don’t know what to do with that answer, really. I gave you some data (80%+ of requests downloads over the last month were Python 2), and you responded with “it doesn’t cause us problems”.
> And indeed it doesn't. Unless the target user base for pip is widely
> different than Python's, it shouldn't cause you any problems either.
Maybe not now, but I think it’s fair to say that it did, right? As I recall, Python spent a long time with two fully supported Python versions, and then an even longer time with a version that was getting bugfixes. Tell me, which did you get more feedback on during that time?
Generally speaking it is fair to say that at this point *every line of code in Requests* is exercised or depended on by one of our users. If we write new code available to a small fraction of them, and it is in any way sizeable, then that stops being true. Again, we should look at the fact that most libraries that successfully support Python 2 and Python 3 do so through having codebases that share as much code as possible between the two implementations. Each line of code that is exercised in only one implementation becomes a vector for a long, lingering bug.
Anyway, all I know is that the last big project to do this kind of hard cut was Python, and while many of us are glad that Python 3 is real and glad that we pushed through the pain, I don’t think anyone would argue that the move was painless. A lesson can be learned there, especially for Requests which is not currently nursing a problem as fundamental to it as Python was.
>> As a final note, because I think we’re getting into the weeds here: this is not *necessary*. None of this is *necessary*. Requests exists, and works today.
> And pip could even bundle a frozen 2.7-compatible version of Requests if
> it wanted/needed to…
Sure, if pip wants to internalise supporting and maintaining that version. One of the advantages of the pip/Requests relationship is that pip gets to stop worrying about HTTP: if there’s a HTTP problem, that’s on someone else to fix. Bundling that would remove that advantage.
>> Let me be clear that there is no intention to use either Tornado or
> Twisted’s HTTP/1.1 parsers or engines. [...] Requests very much intends
> to use our own HTTP logic, not least because we’re sick of relying on
> someone else’s.
> Then the PEP is really wrong or misleading in the way it states its own
How so? TLS is not a part of the HTTP parser. It’s an intermediary layer between the transport (resolutely owned by the network layer in Twisted/Tornado) and the parsing layer (resolutely owned by Requests). Ideally we would not roll our own.
More information about the Python-Dev