-
Notifications
You must be signed in to change notification settings - Fork 5.9k
API 7.3: ChatFullInfo, Readmes #4242
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey! Looks like you edited README.rst or README_RAW.rst. I'm just a friendly reminder to apply relevant changes to both of those files :)
Bibo-Joshi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @harshil21 thanks for getting started. You were in fact a bit too quick for me :D To ensure backward compatibility in accordance to our stability policy, I would like to instead use the following approach:
- Keep the arguments & attributes in
Chat, just deprecate them as we usually do. This ensures backward compatibility for the class. - Make
ChatFullInfoa subclass ofChatand add only arguments/attributes thatChatFullChatInfohas in addition toChat. Avoiding to issue deprecation warnings inChatFullInfocan be done maybe by implementing a helper methodChat._do_warnthatChatFullInfocan override. By subclassing, the return value ofget_chatis backward compatible as well and should avoid code duplication for shortcut methods & properties. Document that theChatbase class will be removed in the future. - On the next api release, we can introduce a new private
_ChatBaseclass that bothChatandChatFullInfoinherit from.
what do you think about overriding |
Bibo-Joshi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much for the updates! Just two nitpicks
Bibo-Joshi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
basically LGTM, just two questions out of curiosity :)
Checklist
.. versionadded:: NEXT.VERSION,.. versionchanged:: NEXT.VERSIONor.. deprecated:: NEXT.VERSIONto the docstrings for user facing changes (for methods/class descriptions, arguments and attributes)CSI standard <https://standards.mousepawmedia.com/en/stable/csi.html>__AUTHORS.rst(optional)__all__sStability Policy <https://docs.python-telegram-bot.org/stability_policy.html>_ in case of deprecations or changes to documented behaviorIf the PR contains API changes (otherwise, you can ignore this passage)
Checked the Bot API specific sections of the Stability Policy
New classes:
self._id_attrsand corresponding documentation__init__acceptsapi_kwargsas kw-onlyAdded new shortcuts:
~telegram.Chat& :class:~telegram.Userfor all methods that acceptchat/user_id~telegram.Messagefor all methods that acceptchat_idandmessage_id~telegram.Messageshortcuts: Addeddo_quoteargument if methods acceptsreply_to_message_id~telegram.CallbackQueryfor all methods that accept eitherchat_idandmessage_idorinline_message_idIf relevant:
telegram.constantsand shortcuts to them as class variablestelegram.Message.effective_attachment~telegram.ext.ConversationHandler_extbot.pybot_methods.rstREADME.rstandREADME_RAW.rst(including the badge), as well astelegram.constants.BOT_API_VERSION_INFOtelegram.ext.ExtBotfor new methods that either accept areply_markupin some form or have a return type that is/contains :class:~telegram.Message