[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7 (original) (raw)
Cory Benfield cory at lukasa.co.uk
Thu Jun 1 09:37:55 EDT 2017
- Previous message (by thread): [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
- Next message (by thread): [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 motivations.
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.
Cory
- Previous message (by thread): [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
- Next message (by thread): [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]