4 ms·
> Python already has exactly that, and has had that for ages. And the point is that this should be fixed, instead of adding yet another clunky way of doing the
by ori_b 7y ago
> Python already has exactly that, and has had that for ages.
And the point is that this should be fixed, instead of adding yet another clunky way of doing the same thing.
> Besides the "cumbersome interface" is irrelevant, as it would be easy to wrap and forget about it, the same way nobody really uses urllib directly.
Then why bother having it, if the only reason for it to exist is so that it can be wrapped? That's just stacking layers of turd.
- baq 7y agoAlmost nobody writes assembly nowadays, but I don’t see anyone wanting it gone. This is assembly. Don’t want to wrap it yourself, fine, don’t complain that it exists.
- cyphar 7y agoYou could implement requests without urllib. You cannot implement C without assembly. That's the distinction between useful layers of abstraction and pointless ones. If a better interface to subinterpreters is bound to be developed, then that should've been the stdlib interface in the first place.
- coldtea 7y ago>You could implement requests without urllib. Yes, but you couldn't do more fine-grained than requests things, unless you did them from excruciatingly lower level (e.g. sockets).
- coldtea 7y ago>And the point is that this should be fixed, instead of adding yet another clunky way of doing the same thing. Well, unless we have a (1) capable (2) volunteer the point is moot. Those who actually work on Python development accessed both scenarios and found adding the "yet another clunky way" if not optimal, a more feasible, easier and better use of their limited time. >Then why bother having it, if the only reason for it to exist is so that it can be wrapped? Because lower level primitives can be used in many useful ways than some constraining higher level construct, but the latter is still nice to have.