4 ms·
stdlib is where things go to die. Backwards compatibility, limits on dependencies, release cycles, etc all make development a pain and discourage potential cont
by Frotag 4y ago
stdlib is where things go to die. Backwards compatibility, limits on dependencies, release cycles, etc all make development a pain and discourage potential contributions. Or so I've read.
Here's one discussion about it in the requests repo
https://github.com/psf/requests/issues/2424 https://github.com/psf/requests/issues/2424
- tyingq 4y agoStdlib may not be the answer, but the current setup does make urllib3 suffer in anonymity...since for many it's hidden under the requests module.
- dec0dedab0de 4y agoI read that at the time, but that was 7 years ago. Requests has been pretty much backward compatible for that whole time. They could still have active developments available in pypi for people who need the newer features, but python has been dropping minor releases about once a year, that should be plenty fast for new features in requests.
- bodyfour 4y agostdlib is also where things go to get used, though. Coding against a pile of external python modules is perfectly reasonable when you're building something "app scale" -- i.e. something that is going to be spread across many files and installed in a container or venv. However, when writing something at "script scale" I just don't want to deal with all of that. I want to write something that I can deploy as a single file and not end up dealing with missing python dependencies every time. This means I'm using the old urllib and such more often than I'd like. It's a shame that there doesn't seem to be much flow of functionality into stdlib at all any more. For my needs, I wish "requests" and "yaml" were in that set, although I'm sure other people have their own opinions on that.