-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PreparedRequest check: use duck typing? #3102
Comments
That's a good question. Generally speaking it seems like a bad idea to pass objects from one form of a library to another form (it's not even really possible to do in Python unless the namespacing has gone all to hell. One way we could resolve this problem is to flip the check to catch the specific error case we're explicitly worried about ( |
Sounds good! |
Previously we checked that the `request` being sent was an instance of a PreparedRequest. If a user somehow created a PreparedRequest using a different Requests library instance, this check makes the request un-sendable. (This happened recently - unbeknownst to me, my server was running an outdated version of pip, vulnerable to this issue - pypa/pip#1489, which creates multiple subdirectories (src/requests, src/requests/requests) when you rerun pip install --target. So the PreparedRequest was being created in one version of the library and compared against the other version of the library, and throwing this exception, even though they were both PreparedRequest instances!) It would probably be preferable to check the object's behavior (instead of its type), but a PreparedRequest has a lot of behavior, and it wouldn't be really feasible or allow us to provide a helpful error message to check all of it here. Instead flip the conditional to guard against the user sending an unprepared Request, which should still give us most of the benefits of the better error message. Fixes psf#3102
Okay, this is admittedly an edge case.
I was attempting to deploy to AWS from a CI server, and
boto3
was returning this stack trace:The related code in Requests is here:
This was failing because unbeknownst to me, the server was running an outdated version of
pip
, vulnerable to this issue, which creates multiple subdirectories (src/requests
,src/requests/requests
) when you rerunpip install --target
: pypa/pip#1489. So the PreparedRequest was being created in one version of the library and compared against the other version of the library, and throwing this exception, even though they were both PreparedRequest instances!I'm not sure of the best reference here, but as I understand it, it's preferable to check an object's behavior rather than its type, see for example Alex Martelli's message here:
I may be the only human in the history of existence to hit this exact edge case, but it seems like Requests could still perform the request. Is there a better way to check for the necessary behaviour?
The text was updated successfully, but these errors were encountered: