Skip to content
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

Media uploading #455

Open
fernand0 opened this issue Oct 13, 2022 · 1 comment
Open

Media uploading #455

fernand0 opened this issue Oct 13, 2022 · 1 comment

Comments

@fernand0
Copy link
Contributor

I've been testing media uploading following the examples provided in the README. The method is based on creating a new instance of the Twitter class:

 t_upload = Twitter(domain='upload.twitter.com', auth=OAuth(token, token_secret, consumer_key, consumer_secret))

And later using the old instance to add the uploaded media to a tweet:

  t.statuses.update(status="PTT ★", media_ids=",".join([id_img1, id_img2]))

I've been testing a different approach, that could be like:

  1. Changing the domain in the instance of the Twitter class:

    t.domain = 'upload.twitter.com'

  2. Uploading the images with the original instance of the Twitter class (but with different domain).

  3. Changing the domain to the original one:

    t.domain = 'api.twitter.com'

  4. Publishing the tweet containing the images.

I was wondering if this approach is ok (and, I believe, more simple than creating a secondary instance to upload images). If this is true, maybe it would be nice to modify de upload methods to change internally the domain and so on. Or, at least, maybe providing the adequate methods for changing the domains when needed.

@boogheta
Copy link
Collaborator

boogheta commented Oct 17, 2022

Hello @fernand0 I've never thought of using it like this, but since the TwitterCall class's domain attribute is accessible and is reread at every API call, I don't see why your proposition wouldn't be a valid solution. You can propose a PR for the documentation if you like.
Regarding doing this internally, this would mean hardcoding attachment of some api routes to some specific domains which is hard to maintain in the long run as new routes keep appearing, but I see the interest of having it for this quite specific and annoying case. In which case we should just ensure that the user can force the domain of his choice in any case and not let the magic block other wishes. I'll be happy to review a PR for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants