equality test forInlineKeyboardMarkup fails on Py2.7. Don't know why, but don't really care 🤷‍♂

thanks for asking me to review, but I gonna decline, this is too much for me :D

test_set_game_score_1 is the one again …

Just a thought: should we makeTelegramObject.__eq__ raise an error or warning, if it's comparing two objects, one of which has an emtpy_id_attrs tuple, i.e. it's not comparable?

Edit: I just went for it (see commit below)

• Added documentation, also for the classes, who already had id attrs.
• Addressed some of the above mentioned stuff
• In the process, I addedmessage.chat to the id attrs, asmessage_id is not unique across chats. Strictly speaking this is somewhat breaking. Then again, the behaviour wasn't documented yet, so I'd sleep well with that …
• Coday complains: Access to a protected member _id_attrs of a client class:if other._id_attrs == (): That's okay imo.
• py3.6 fails onset_game_score …

Sorry, I forgot the actual issue I have with this: Documentation. I like that you wrote down what gets compared where, but I dont like that being before the attributes of the object. I feel like most users will want to read about attributes rather then what gets compared if they compare this object, which means they have to read over this all the time when they open the docs. What about putting the what-gets-compared paragraph at the end, after the parameters?

What about putting the what-gets-compared paragraph at the end, after the parameters?

I fear that it's heard to find it there, especially in the docs of classes with many attributes. And it's only 1-3 lines, so it doesn't take up too much space, imo … The alternative would be to have an explicit docstring for__eq__(), but I don't think that I like that …

Some concerns about this PR were voiced offline. I'll try to summarize in hopes of not missing the point:

• Implementing__eq__() to compare only a subset of a classes attributes will be unintuitive for users
• This is especially true for TG objects that can change, e.g. twoMessage objects will be equal when testing formessage_id only, while maybe having different text
• Custom comparison by attributes in easy to achive, so there is no reason to implement__eq__()

I'd like to add that this argumentation not only sees harm in this PR but also in the current use of_id_attrs

While I don't agree with this argumentation, I find the arguments important and like to have this properly discussed before going for merge. For completeness sake, here is my line of thought:

• We already have__eq__() implemented for objects with some kind of ID. So we could a) remove that capability, b) leave it as is, or c) extend it to all/most objects
• The default implementation of__eq__() is useless - I'd rather useis, if I want to compare by object identity. So giving objects a meaningful comparison is crucial imo, which is why I went for c)
• Currently this PR aims to set_id_attrs to the attrs that uniquely identify an object, i.e. this comparison is the "correct" one in most use cases
• This PR adds documentation, so== is no black box and if users need a different comparison, they can still implement that

We discussed the PR in the dev chat again and decided to merge.
I went over the changes once again ad made some minor corrections.
py3.8 fail unrelated, codacy has v13 issues. Merging.