4 ms·

I think both of them should be in the standard library at this point. The API has been fairly stable for over 5 years.

hotfixguru 4y ago
Web and release cycles don’t always go hand in hand, though.
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 ago
  Stdlib 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 ago
  I 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 ago
  stdlib 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.

Web and release cycles don’t always go hand in hand, though.

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 ago
Stdlib 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 ago
I 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 ago
stdlib 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.