Repository navigation
Overhaul some of the stubs for requests/urllib3 #2612
Description
Specifically, it looks like the stubs for requests date back to a time when urllib3 was vendored with requests. These days, it looks like requests doesn't vendor it anymore and instead uses urllib3 from pypi.
I think that urllib3 should become it's own top-level stubs (not part of requests) and some of the requests stubs should probably be revisited. In order to limit scope, the particular stubs that I've been fighting with in requests.adapters -- BaseAdaptor.send doesn't accept proxies (even though it should), HTTPAdaptor.send has virtually no type annotations when BaseAdaptor.send does -- I think they should be basically the same...
What do you think?
Activity
JelleZijlstra commentedon Nov 20, 2018
The
urllib3issue is something we don't have a great answer for right now: what to do if different versions of a library have very different types? I'm not sure how long it has been sincerequestsunvendoredurllib3; if it's been a while I'd be more OK with removing therequests.packages.urllib3stubs. In this case, people probably shouldn't have been usingrequests.packages.urllib3anyway, since it wasrequests's private copy.I haven't looked into the more specific issue you mentioned with
adapters, but much of therequestsstubs can probably be improved. PRs are welcome.mgilson-argo commentedon Nov 20, 2018
Looking at the git history, it appears that
urllib3was split off/unvendored about 1 and a half years ago.One of the problems with the current stubs are that the
requestsdocumentation ask you to pass things like aurrlib3.util.retry.Retry, but the stubs are still referencing the definitions fromrequests.packageswhich isn't correct these days. I would guess that the timescales we're talking about are long enough that it's probably safe to switch over (maybe askingstubgento re-generate stubs forurllib3or something rather than trying to port over the old stuff by hand)As for
I think that's a very valid question -- And why I hope that people really adopt PEP-561. Then it's the library's problem rather than typeshed's ... Time will tell.
Is
typing_extensions.Protocolfair game in typeshed? This doesn't actually solve the problem completely, but defining interfaces rather than concrete types could help with the vendored/unvendored problem (where you have types that are equivalent, but coming from disparate sources)JelleZijlstra commentedon Nov 20, 2018
Yes, Protocols are fine to use in typeshed.
ilevkivskyi commentedon Nov 20, 2018
Moreover, you can just write
from typing import Protocolin stubs.koffie commentedon May 21, 2021
Can this be closed since urllib3/urllib3#1897 is seeing more action than is seen here?
Akuli commentedon May 21, 2021
If our requests stubs just
import urllib3, shouldtypes-requeststhen depend onurllib3? I thinktypes-foopackages can have dependencies only to othertypes-foopackages.ciaransweet commentedon Sep 21, 2021
Hey folks, I'm going around in circles in issues, this one is still open though 🤣
I'm getting
error: Skipping analyzing "urllib3": found module but no type hints or library stubswhen runningmypy- Is there a working/in development package forurllib3stubs?srittau commentedon Sep 21, 2021
This depends on #5952. Then we can update the requests stubs to depend on urllib3 and remove the vendored urllib3 stubs.
ciaransweet commentedon Sep 21, 2021
@srittau so something is in the works but not ready to go?
srittau commentedon Sep 21, 2021
In the works as in "I need to find the time to implement it".
ciaransweet commentedon Sep 21, 2021
More than fair enough 😄 Just wanted to make sure I wasn't missing one ready to go!
AlexWaygood commentedon Jun 12, 2022
urllib3following Add urllib3 stubs #6858.requestsstubs now usetypes-urllib3following Use types-urllib3 for requests #6859.I believe this means that most of the problems discussed in this issue are now solved.
I'm not sure if this is still a problem four years on. If it is, please feel free to open a new issue and/or PR :)