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
API 7.3: ChatFullInfo, Readmes #4242
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 :)
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
ChatFullInfo
a subclass ofChat
and add only arguments/attributes thatChatFullChatInfo
has in addition toChat
. Avoiding to issue deprecation warnings inChatFullInfo
can be done maybe by implementing a helper methodChat._do_warn
thatChatFullInfo
can override. By subclassing, the return value ofget_chat
is backward compatible as well and should avoid code duplication for shortcut methods & properties. Document that theChat
base class will be removed in the future. - On the next api release, we can introduce a new private
_ChatBase
class that bothChat
andChatFullInfo
inherit from.
what do you think about overriding |
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
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.VERSION
or.. deprecated:: NEXT.VERSION
to 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_attrs
and corresponding documentation__init__
acceptsapi_kwargs
as kw-onlyAdded new shortcuts:
~telegram.Chat
& :class:~telegram.User
for all methods that acceptchat/user_id
~telegram.Message
for all methods that acceptchat_id
andmessage_id
~telegram.Message
shortcuts: Addeddo_quote
argument if methods acceptsreply_to_message_id
~telegram.CallbackQuery
for all methods that accept eitherchat_id
andmessage_id
orinline_message_id
If relevant:
telegram.constants
and shortcuts to them as class variablestelegram.Message.effective_attachment
~telegram.ext.ConversationHandler
_extbot.py
bot_methods.rst
README.rst
andREADME_RAW.rst
(including the badge), as well astelegram.constants.BOT_API_VERSION_INFO
telegram.ext.ExtBot
for new methods that either accept areply_markup
in some form or have a return type that is/contains :class:~telegram.Message