You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
requests.packages missing in types-requests 2.27.5 #6893
We removed it in #6859. That PR doesn't make clear why the copy in requests was removed; it seems to still exist in the most recent release of requests.
We removed it in #6859. That PR doesn't make clear why the copy in requests was removed; it seems to still exist in the most recent release of requests.
Yeah, that was what I saw as well, that it still seems to be in requests.
The original plan was to import the urllib3 stubs from types-urllib3 into requests.packages.urllib3 as runtime does. Unfortunately, this isn't easily possible. The requests.packages.urllib3 were quite outdated, and it's not clear which version of urllib3 we should use. It would also mean that we have to maintain two copies of urllib3. I recommend to import urllib3 imports directly from urllib3 instead of requests.packages.urllib3.
The code example in this issue needs the same copy of urllib3 as requests uses internally, because it is suppressing a warning that requests generates while it is using its urllib3. I think we should add back requests/packages/__init__.pyi with a __getattr__ incomplete marker, so that the import will at least work, even if it isn't very nicely type checked.
The __getattr__() marker is a good idea. The alternative is (your idea, I think) to basically copy the urllib3 structure and do a from urllib.xyz import * in each file, although I'd like to avoid that.
Activity
JelleZijlstra commentedon Jan 11, 2022
We removed it in #6859. That PR doesn't make clear why the copy in
requestswas removed; it seems to still exist in the most recent release of requests.wpwood commentedon Jan 11, 2022
Yeah, that was what I saw as well, that it still seems to be in
requests.srittau commentedon Jan 11, 2022
The original plan was to import the urllib3 stubs from
types-urllib3intorequests.packages.urllib3as runtime does. Unfortunately, this isn't easily possible. Therequests.packages.urllib3were quite outdated, and it's not clear which version ofurllib3we should use. It would also mean that we have to maintain two copies of urllib3. I recommend to import urllib3 imports directly fromurllib3instead ofrequests.packages.urllib3.Akuli commentedon Jan 12, 2022
The code example in this issue needs the same copy of urllib3 as requests uses internally, because it is suppressing a warning that requests generates while it is using its urllib3. I think we should add back
requests/packages/__init__.pyiwith a__getattr__incomplete marker, so that the import will at least work, even if it isn't very nicely type checked.srittau commentedon Jan 12, 2022
The
__getattr__()marker is a good idea. The alternative is (your idea, I think) to basically copy the urllib3 structure and do afrom urllib.xyz import *in each file, although I'd like to avoid that.andersk commentedon Jan 13, 2022
requestsno longer vendorsurllib3or any other packages as of 2.16.0 (psf/requests#4067), so there’s no longer a concern as to which version to use.Import urllib3 directly.
Use dedicated urllib3 type stubs
Typing (#128)
srittau commentedon Jul 12, 2022
Closing per @andersk's comment.
Change urllib3 import to a top-level import and explicitly add urllib…
Change urllib3 import to a top-level import and explicitly add urllib…
remove dependency on urllib3 vendored in requests since it is not mai…
fix types (#684)
fix types (#684)