TG classes that are used for input only

If I understand this correctly, you mean these classes aren't used by Telegram and only by Users to make a request. So I dont get what you mean with "minor risk of TG sending them back to us"

So I dont get what you mean with "minor risk of TG sending them back to us"

The important part here is "at some point", meaning after a future bot api release. E.g. TG might decide to to have get_my_command return a BotCommandScope for something. If the same release adds another attribute to BotCommandScope, the code would blow up, if BotCommandScope doesn't accept kwargs. Surely unlikely that something like this happens, but not impossible.

Ah I see. Thats a risk I would say is worth to take. I would drop kwargs and include the api kwargs parameter like we do with requests.

Ah I see. Thats a risk I would say is worth to take. I would drop kwargs and include the api kwargs parameter like we do with requests.

My comment on this in dev chat seems to have gone unnoticed: What would api_kwargs be good for here? They wouldn't help us with de_json …

... right, weird comment.

My stance is the same, I would take the risk that telegram might screw it up and rather have a better user experience and not swallowing errors.

Breakfast idea: instead of blindly doing cls(**json_dict) in de_json, we can use inspect.signature(cls) to filter out any keys from json_dict that are not expected by cls.__init__.
For classes that are not exclusively for input (e.g. those that we receive from TG), just using **kwargs is probably more effective. But we could use this logic for classes like BotCommandScope and InputMedia* as fail-safe. E.g. it is some maybe not highly effecient logic that can safe us if needed, but likely won't be called at all.

hm. so you want to fail then in the function if a keyword is unexpected, and you want to keep the kwargs parameter?

No, I want to remove **kwargs and still make it work in case we actually do need to de-json one of the classes in question. Basically the Dismissal of additional kwargs section of #2698 (comment) :)

ah well that sounds like a pretty good approach actually.

Closed by #3233