3 ms·

> which happens for things not in the standard library. So to be clear you don't use Requests right? Because there is HTTP client handling right in the Python

> which happens for things not in the standard library. So to be clear you don't use Requests right? Because there is HTTP client handling right in the Python standard library, and yet it sure seems like most Python programmers use Requests, because it's better.

coldtea 3y ago
Did you miss the part where I say "[and] no de facto standard"? Requests is a de facto standard, and I do use it. But besides having a clear, well maintained, de facto standard being OK too (as I wrote), it's also great that I don't have to use Requests, as I can write for urllib3 and know that my project will just work everywhere with no added deps - which I do for simpler stuff. Heck Requests itself is using urllib under the covers, which also has some benefits of uniform implementation of protocols and such.
- tialaramex 3y ago
  You said that the stdlib needs to provide it first, you were very clear about that. So a "de facto standard" can't in fact exist, such claims while they probably feel correct to you make a mockery of your demand that the stdlib should do it first - if it did then Requests can't exist. And for what it's worth I agree with you about that doing it first, on the whole a stdlib should aim to do it first if they're doing it at all. Take Microsoft's belated decision to ship a JSON implementation for .NET. Obviously meanwhile a de facto standard took hold, Newtonsoft, and of course the Microsoft library isn't a drop-in replacement. Result, more complexity, more training, negligible real benefit. I just disagree that they should aim to do it all.
  - coldtea 3y ago
    >You said that the stdlib needs to provide it first, you were very clear about that. Not clear enough apparently :) What I said is: (a) I see "Lack of standard library support for X brought 5 competing libraries for the same X functionality, (b) no de facto standard, (c) and projects using incompatible implementations and versions maintained in different states of disarray" as a problem. That's 3 things, and the 3rd occurs because of a lack of either or both of the first two. So, I didn't say stdlib "needs to provide it first", except if by that you just mean the order in which I wrote it. To spell it out, what I'm saying is: Not having something in stdlib AND not having a defacto standard for it either, and THUS getting many incompatible implementations - that's a bigger problem than stdlib scope creep. >And for what it's worth I agree with you about that doing it first, on the whole a stdlib should aim to do it first if they're doing it at all. Take Microsoft's belated decision to ship a JSON implementation for .NET. Obviously meanwhile a de facto standard took hold, Newtonsoft, and of course the Microsoft library isn't a drop-in replacement. It's good to do it first and get it right, but they can as well also do this: embed the emerged de facto standard as is, if they decide to do it later. That's what Java should have done with Joda-Time for example.
    - tialaramex 3y ago
      Maybe the problem is that you don't know what "de facto" means? You seem to imagine that the first prototype of Requests was uploaded and aha - it's a "de facto standard" so now we're fine. No, the way "de facto" standards happen is it becomes apparent over considerable time that in fact this is what everybody does, it is the standard de facto. This is how the IETF's Internet standards (as opposed to RFCs) work for example. Requests became a de facto standard, meanwhile other people wrote libraries "for the same X functionality" which did not. So in fact the thing you claim is unacceptable and happens third actually happens second and the state you claim is OK and precludes that, in fact happened later and as a consequence of the thing you think is unacceptable.

coldtea 3y ago

Did you miss the part where I say "[and] no de facto standard"? Requests is a de facto standard, and I do use it. But besides having a clear, well maintained, de facto standard being OK too (as I wrote), it's also great that I don't have to use Requests, as I can write for urllib3 and know that my project will just work everywhere with no added deps - which I do for simpler stuff. Heck Requests itself is using urllib under the covers, which also has some benefits of uniform implementation of protocols and such.

tialaramex 3y ago
You said that the stdlib needs to provide it first, you were very clear about that. So a "de facto standard" can't in fact exist, such claims while they probably feel correct to you make a mockery of your demand that the stdlib should do it first - if it did then Requests can't exist. And for what it's worth I agree with you about that doing it first, on the whole a stdlib should aim to do it first if they're doing it at all. Take Microsoft's belated decision to ship a JSON implementation for .NET. Obviously meanwhile a de facto standard took hold, Newtonsoft, and of course the Microsoft library isn't a drop-in replacement. Result, more complexity, more training, negligible real benefit. I just disagree that they should aim to do it all.
- coldtea 3y ago
  >You said that the stdlib needs to provide it first, you were very clear about that. Not clear enough apparently :) What I said is: (a) I see "Lack of standard library support for X brought 5 competing libraries for the same X functionality, (b) no de facto standard, (c) and projects using incompatible implementations and versions maintained in different states of disarray" as a problem. That's 3 things, and the 3rd occurs because of a lack of either or both of the first two. So, I didn't say stdlib "needs to provide it first", except if by that you just mean the order in which I wrote it. To spell it out, what I'm saying is: Not having something in stdlib AND not having a defacto standard for it either, and THUS getting many incompatible implementations - that's a bigger problem than stdlib scope creep. >And for what it's worth I agree with you about that doing it first, on the whole a stdlib should aim to do it first if they're doing it at all. Take Microsoft's belated decision to ship a JSON implementation for .NET. Obviously meanwhile a de facto standard took hold, Newtonsoft, and of course the Microsoft library isn't a drop-in replacement. It's good to do it first and get it right, but they can as well also do this: embed the emerged de facto standard as is, if they decide to do it later. That's what Java should have done with Joda-Time for example.
  - tialaramex 3y ago
    Maybe the problem is that you don't know what "de facto" means? You seem to imagine that the first prototype of Requests was uploaded and aha - it's a "de facto standard" so now we're fine. No, the way "de facto" standards happen is it becomes apparent over considerable time that in fact this is what everybody does, it is the standard de facto. This is how the IETF's Internet standards (as opposed to RFCs) work for example. Requests became a de facto standard, meanwhile other people wrote libraries "for the same X functionality" which did not. So in fact the thing you claim is unacceptable and happens third actually happens second and the state you claim is OK and precludes that, in fact happened later and as a consequence of the thing you think is unacceptable.