-
-
Notifications
You must be signed in to change notification settings - Fork 22
Ensure import urllib3
can succeed even if trio and twisted aren't installed
#25
Comments
Thinking about it, we probably want to not even try to import So what should this placeholder look like? A few options: # Strings?
AsyncPoolManager(backend="trio")
# Some sort of enum constant?
AsyncPoolManager(backend=TRIO)
# For twisted/asyncio we'll want to be able to specify the reactor/loop...
AsyncPoolManager(backend=Twisted(reactor=myreactor))
AsyncPoolManager(backend="twisted", backend_args=dict(reactor=myreactor))
AsyncPoolManager(backend=Backend("twisted", reactor=myreactor))
AsyncPoolManager(backend=Backend(Backend.TWISTED, reactor=myreactor)) Whatever we choose will probably leak into higher levels of the stack like requests – if requests uses urllib3 under the hood, then requests's users will want to be able to specify any of the supported backends for requests to use, and ideally when urllib3 gets a new backend it shouldn't require code changes to requests. So CC: @kennethreitz I know @Lukasa will be grumpy about the string version, because pyflakes can't catch if you write A downside to constants though is getting everyone to agree on them. We don't want people to write things like: requests.AsyncSession(backend=urllib3.something) because the I'm kind of tempted to say that the options are: # uses the default reactor
AsyncPoolManager(backend="twisted")
# same as above, but more verbose
AsyncPoolManager(backend=Backend("twisted"))
# if you want to specify arguments
AsyncPoolManager(backend=Backend("twisted", reactor=...)) And we can even make the class Backend:
def __init__(self, backend_name, **kwargs):
self._backend_name = backend_name
self._kwargs = kwargs Requests etc. can re-export this, but this also allows us to skip |
I worry that exporting an object would introduce a lot of complexity for the average user (who is likely to be using a wrapper around urllib), so I'm in favour of:
As long as we go down in flames when the user misspells their backend (and by extension their backend_args), I think this is OK. |
@kennethreitz Since requests3/requests-core will consume this API, what do you think of the string approach: |
I caught @kennethreitz on freenode #positivepython:
So unless anyone else objects, I think let's go with my proposal at the end of this comment, with the duck-typeable |
Fixed by #47 |
And also give a useful error message when we try to import a repository that is not syncified.
See https://python3statement.org/practicalities/ for a good way to fail at import time.
The text was updated successfully, but these errors were encountered: