3 ms·

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 probabl

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

>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.