-
Notifications
You must be signed in to change notification settings - Fork 198
Add function to list muted accounts #480
Comments
Thanks! Yes, indeed is something I found missing. Fixing #467 would also help if people over-muted |
I think the problem is that |
Yes, PR are more than welcomed, if you have time send it please. Just not sure when I'll merge them. As currently I can't use the github actions to test the package, and I would like to prioritize fixing the long-standing open issues following #471 |
I think the most important thing is to get the tests working again, but I don't see an issue that tracks that? |
Indeed! Maybe I should create one. There are a couple of things with tests:
|
I'll wait until you're done with #527, before working on this issue, but I've been starting to think about the interface a little bit. We might as well tackle blocking at the same time in the same fashion, so I was thinking of the following six functions: user_mute() # POST mutes/users/create
user_unmute() # POST mutes/users/destroy
user_block() # POST blocks/create
user_unblock() # POST blocks/destroy
user_list_muted() # GET blocks/ids
user_list_blocked() # GET mutes/users/ids I think it makes the most sense to start the function names with the "type" of thing (user, tweet, list, message) because I think that's the most obvious part — you might not know exactly what type of operation you want to apply, but it seems likely that you'll know what to apply it to. Then we follow with a verb, matching how people normally talk about these operations.
user_mute() # POST mutes/users/create
user_unmute() # POST mutes/users/destroy
user_block() # POST blocks/create
user_unblock() # POST blocks/destroy
self_muted() # GET blocks/ids
self_blocked() # GET mutes/users/ids The downside of this naming convention is that it requires the user to understand the different words associated with muting (i.e. mute, unmute, muted). Another approach would be to adhere closer to the twitter url scheme: user_mute_create() # POST mutes/users/create
user_mute_destroy() # POST mutes/users/destroy
user_mute_list() # GET blocks/ids
user_block_create() # POST blocks/create
user_block_destroy() # POST blocks/destroy
user_block_list() # GET mutes/users/ids But that's a little harder to understand because you have to think of mute and block as nouns, not verbs. |
Not sure how people use rtweet (would like to explore, perhaps by looking at the dependencies), but to me it is the contrary I know what I want to do so I know what I need. What about a shorter direct more similar to the app/web names like: tweet()
delete()
mute() # POST mutes/users/create
unmute() # POST mutes/users/destroy
muted() # GET blocks/ids
block()
unblock()
blocked()
lists()
enlist()
un/delist() The major downside I see is that they are quite similar mute/muted |
My worry with just using verbs is that the chances of finding good verbs for every single operation is low — e.g. at some point you're going to realise that there's something else you want to |
Sorry, been thinking about this for a while. I think (now) your last proposal makes more sense mimic as possible the Twitter API. It will make it easier to expand to new endpoints and we can insert "_v2" if there is a conflict with new v2 API. |
Coming over from #638. I lean more towards @hadley's suggestion because the verb names aren't always very obvious (e.g., it get_timeline, not user_tweets). And it'd be nice to differentiate the global actions (like search) from the actions on an item or group of items. Here's a stab at a naming convention:
Apply to tweet:
Apply to user:
Apply to self
The |
Thinking more about the naming scheme, should it be |
eg. https://developer.twitter.com/en/docs/twitter-api/v1/accounts-and-users/mute-block-report-users/api-reference/get-mutes-users-ids
The text was updated successfully, but these errors were encountered: