-
-
Notifications
You must be signed in to change notification settings - Fork 423
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
AttributeError: 'PreparedRequest' object has no attribute 'data' #1
Comments
Yes, there isn't
|
Pull Request? =D |
@Lukasa sure 👍 |
I'm so not keeping up with the times. Just noticed randomly that this was split into it's own repo and broken with the requests refactoring while I was debugging some old code. I quick-fixed it in passing locally and was just about to add an issue here to remember to one day clean it up and push it. Lo and behold you guys are already on it. I love open source =) hasattr(r, 'files') will however cause trouble since r in this case is a PreparedRequest without that attribute. If the prepare_auth was moved to after prepare_body (https://github.com/kennethreitz/requests/blob/master/requests/models.py#L201) then it would probably be fine just omitting the files check as the content type should be set. I've not tested any multipart data yet tho so might be mistaken, I'll dig deeper later this week if none else beats me to it. |
Please get back to us with the result of your investigation. In the absence of good tests for this code, we need as much user feedback as possible. =) |
Well the reason the files check was there in the first place was because of the internal order of things in pre-1.0 requests where the content type was not always set, especially not before the auth call. The only thing this extension needs to do is to sort out some unicode issues (or else stuff will break deep down in other libraries, or so it used to) and help figure out content-type if not set. I'll try and crave an hour or two out of tomorrow and add some tests for this. Anyone know if there is a particular reason for prepare_body coming after prepare_auth? If not that's a good place to start making life easier for content-type guessing. Oh btw, and there is no full_url anymore, just url. |
This library has had only one change to bring it up to date with v1 of Requests, and that was #3. I'm spread way too thin to get around to this any time soon, so any help you can provide would be awesome. =) |
decoded_body and r.body being None under certain circumstances might also cause grief. I'll need to update myself a bit on how things are meant to be done with the new requests structure then patch it. That might take a day or two so don't hesitate to beat me to it... |
Know the feeling =) I'll try and sort it out either here or on oauthlibs side this week. |
Threw together some quick fixes in #4. |
I am so stupid! I have been beating my head against the wall because of this for at least an hour and a half! Please push a new tag and update pypi. Thanks. Until then, does anyone think the current master is ready for prime time? |
@mikofski |
Master works fine and you can see an example flask-twitter use here https://gist.github.com/4487236 Requests has pushed the change and it is included in at least 1.0.4. requests-oauthlib however needs to push master. Note that you still need to provide all input in unicode. After oauthlib pushes 0.4 this will no longer be necessary if your input is utf-8 encoded. However, before I push I need to do some further testing. I'll ping this issue when done. |
Thanks @ib-lundgren & @michaelhelmick! I did ...
which updated me to master and now all is well! |
was this included in a release? I'm seeing this issue now with req 1.2.0 and req-oauthlib 0.3.0 |
It was included and is for certain in 0.3. Make sure that is really the version you are using as I'm unable to replicate this. If it persists please provide a stack trace / code sample. |
16:42:42 # pip freeze -l | grep requests |
sorry, I'll come back with a good sample replicating it soon but time doesn't allow at the moment. :/ I'll try to distill it down tomorrow. |
No worries. One thing that might help you is if you try and setup a new virtualenv and see if you still have the same error.
|
Okay, I see what's going on. It's intentional that data was going away and the preferred attribute is truly body. This pull request doesn't put the data attribute back, it updates requests-oauthlib to not rely on it. We were introspecting response.requests trying to build better error logs. Looks like we'll need to update our code accordingly. Thanks. |
@Lukasa asked me to raise this error in this repo as well:
Hey guys, just wanted to bring this issue forward. With requests 1.0.0
So the error came from when I went to test
Twython
with the newrequests
release.And because it bothered me, I removed
self
from all variables that usedself
likeself.callback_url
Also, I striped the code out of the actual function
get_authentication_tokens
(so that's why you'll see ref to that function in the traceback)Anyways, when I try to run this code I get the error:
The text was updated successfully, but these errors were encountered: