> On 1 Jun 2017, at 14:21, Antoine Pitrou <anto...@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 _______________________________________________ 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
