Additive object fields?

[mr-devs]

So I was playing around with the user_look_ids() method and realized that our data retrieval methods sort of clash with the set_X_fields() methods.

For example...

# Get a list of all user_fields
>>> u_fields = o_utils.ObjectFields.return_user_fields()
>>> u_fields
['created_at', 'description', 'entities', 'id', 'location', 'name', 'pinned_tweet_id', 'profile_image_url', 'protected', 'public_metrics', 'url', 'username', 'verified', 'withheld']
# Set these fields 
>>> ot.set_user_fields(",".join(u_fields))
# Try and pull user_objects only passing the fields ["created_at","username"]
>>> response = ot.user_lookup_ids(user_ids = ids2find, user_fields = ["created_at","username"])
# This still returns all of user fields that I set before. 
>>> response["data"]
[{'created_at': '2013-12-14T04:35:55.000Z', 'url': 'https://t.co/3ZX3TNiZCY', 'id': '2244994945', 'verified': True, 'description': 'The voice of the #TwitterDev team and your official source for updates, news, and events, related to the #TwitterAPI.', 'location': '127.0.0.1', 'username': 'TwitterDev', 'entities': {'url': {'urls': [{'start': 0, 'end': 23, 'url': 'https://t.co/3ZX3TNiZCY', 'expanded_url': 'https://developer.twitter.com/en/community', 'display_url': 'developer.twitter.com/en/community'}]}, 'description': {'hashtags': [{'start': 17, 'end': 28, 'tag': 'TwitterDev'}, {'start': 105, 'end': 116, 'tag': 'TwitterAPI'}]}}, 'public_metrics': {'followers_count': 514823, 'following_count': 2035, 'tweet_count': 3648, 'listed_count': 1682}, 'pinned_tweet_id': '1293593516040269825', 'protected': False, 'profile_image_url': 'https://pbs.twimg.com/profile_images/1283786620521652229/lEODkLTh_normal.jpg', 'name': 'Twitter Dev'}, {'created_at': '2007-05-23T06:01:13.000Z', 'url': 'https://t.co/8IkCzCDr19', 'id': '6253282', 'verified': True, 'description': 'Tweets about changes and service issues. Follow @TwitterDev\xa0for more.', 'username': 'TwitterAPI', 'entities': {'url': {'urls': [{'start': 0, 'end': 23, 'url': 'https://t.co/8IkCzCDr19', 'expanded_url': 'https://developer.twitter.com', 'display_url': 'developer.twitter.com'}]}, 'description': {'mentions': [{'start': 48, 'end': 59, 'username': 'TwitterDev'}]}}, 'public_metrics': {'followers_count': 6056217, 'following_count': 39, 'tweet_count': 3693, 'listed_count': 12267}, 'pinned_tweet_id': '1293595870563381249', 'protected': False, 'profile_image_url': 'https://pbs.twimg.com/profile_images/942858479592554497/BbazLO9L_normal.jpg', 'name': 'Twitter API'}]

So, basically, whenever we are setting or updating the user_fields they simply add onto one another. I am not sure that this is the best approach. My expectation as a user is for whatever I have passed into a data retrieval method to override any previously set object fields.

Having said the above, I think this highlights the question of whether we want to keep these object field setting-methods (i.e. set_user_fields()) separate from the actual data call method (i.e. user_lookup_ids()) or not.

In my opinion, it makes more sense to convert these set_x_fields methods to internal methods which we can use under the hood to update the parameters. Then, we can imply which fields are retrievable from a specific endpoint based on the available parameters within its respective method by simply including only what is available. For example, place fields are available if you're pulling tweet timelines, however, they're not available for your pulling user account information. So we would include "place" as a parameter for the tweet timelines endpoint but not for the user lookup methods.

Hopefully this change wouldn't be too much trouble because I think we can just do the following:

1. Add an underscore in front of the existing "set methods"
2. Add the appropriate parameters to each "data retrieval" method (assuming they would each take a list)
3. Use the now-internal "set methods" within the "data retrieval" methods

What do you guys think?

[yang3kc]

This sounds like a better solution.

[mr-devs]

Okay, great. Based on your refactoring of the followers/following code, I think that the simplest solution is actually just to retire the set_X_field methods and use **kwargs for each method. Then we can detail the docstring with all available options. I am going to close this and open a new issue for this stuff which is a bit cleaner.