-
-
Notifications
You must be signed in to change notification settings - Fork 22
Take two: Ensure import urllib3
can succeed even if trio and twisted aren't installed
#47
Take two: Ensure import urllib3
can succeed even if trio and twisted aren't installed
#47
Conversation
urllib3 is always built with both async and sync support, the real question is "are we in async or bleached code?" We answer this question by testing for async support in a bleached part of the code.
@@ -0,0 +1,12 @@ | |||
class Backend: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if this has to be py2 and 3 compatible, do we need to specify (object)
here to guarantee new style classes?
from ..backends import Backend | ||
|
||
|
||
class Loader: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to specify (object)
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for carrying this over the fence!
I've left some minor comments - assuming that the interface matches the spec that we agreed, this looks mergeable to me.
@oliland Thanks for the review! You really did most of the work, including the import investigation: it was easy to add the finishing touches. I think new-style classes are fine because we only support Python 2.7 which supports them. Did I miss something? |
Sorry, I did not leave you a lot of time to answer, but since you approved and since I think this PR does not contain new Python 2.7 issues, I'll go ahead and merge this. Thanks for your hard work, @oliland! |
This pull request is based on @oliland's PR and completes it:
So the point of that test is simply to know whether we're running in async mode or bleached mode. We can only run in async mode with a Python that supports everything we need (3.6 right now), so the test is simple but has to be in a part of the code that is going to be bleached.
I decided to put this in _async/connection.py because it's the last place that accepts a backend, which means we can validate the backend in a single place. (Which also means that we did not really need to separate normalize_backend and load_backend.)
The history is getting a little complicated but the diff is not that big: I would recommend reviewers to look at the whole diff instead of individual commits.