Alt text - work for issue 316 #319
2 participants
Do we want to make a character length check and an int check on the values of the kwargs? I think we'd also want to integrate posting metadata with the PostMedia*() functions, no?
Maybe as well via PostUpdate()? Since PostUpdate doesn't return the media ID directly (you'd have to go hunting for it in the Status object that's returned) it makes sense to allow passing the parameter so you don't need to do a bunch contortions to post a status, then get the media ID, then upload the alt text.
Also, weird that Twitter's using nested json here; that's the only one in the API right?
it's the only one I found searching for alt_text - all of the other media related ones didn't have anything
I like the idea of bundling it with the other media calls to reduce the number of hops
Looks like requests.post is mangling the JSON payload because it's getting passed via the data= argument rather than the json= argument. Mind if I throw a commit at this?
please adjust/alter this as needed - I created it because I was sitting with the editor open and the twitter dev page and could knock out the start really quickly.
So as this basically works, I'm OK sending this to master with the caveat that maybe we should keep the issue open, since we still don't have real documentation as to how this change is going to affect other endpoints (i.e., how this gets consumed across the API rather than created). What are your thoughts? I'd like this to be available since it's an accessibility improvement and anything is better than the current state of affairs, but it's also somewhat incomplete and not particularly well documented.
I say let's merge it and add a section to the docs about something like "Changes" or something - basically a roadmap of changes from what is old/stable to what is in master branch?
Sounds good. I guess that's like a more fleshed out change log? Something like the migration guide from 2x to 3x? http://python-twitter.readthedocs.io/en/latest/migration_v30.html
yea, the change log seems to be more focused and specific to release/commits.
This would be more of a guided tour thru the new/changed features aimed at someone who is already using it
Reviewed 3 of 3 files at r3, 2 of 2 files at r5.
Review status: all files reviewed at latest revision, all discussions resolved.
Comments from Reviewable
Cool. How do you want to do versioning in that case? Looks like we're still calling master 3.0rc1 (which we should probably fix to be 3.0), so this could be included in a 3.1 release or rolled into 3.0 since that's not official yet.
yea, we should probably deploy 3.0 now -- it's stable enough and people have had time to react.
This change is