API 7.3: ChatFullInfo, Readmes

[harshil21]

Checklist

• Added .. versionadded:: NEXT.VERSION, .. versionchanged:: NEXT.VERSION or .. deprecated:: NEXT.VERSION to the docstrings for user facing changes (for methods/class descriptions, arguments and attributes)
• Created new or adapted existing unit tests
• Documented code changes according to the CSI standard <https://standards.mousepawmedia.com/en/stable/csi.html>__
• Added myself alphabetically to AUTHORS.rst (optional)
• Added new classes & modules to the docs and all suitable __all__ s
• Checked the Stability Policy <https://docs.python-telegram-bot.org/stability_policy.html>_ in case of deprecations or changes to documented behavior

If the PR contains API changes (otherwise, you can ignore this passage)

• Checked the Bot API specific sections of the Stability Policy

• New classes:

  • Added self._id_attrs and corresponding documentation
  • __init__ accepts api_kwargs as kw-only

• Added new shortcuts:

  • In :class:~telegram.Chat & :class:~telegram.User for all methods that accept chat/user_id
  • In :class:~telegram.Message for all methods that accept chat_id and message_id
  • For new :class:~telegram.Message shortcuts: Added do_quote argument if methods accepts reply_to_message_id
  • In :class:~telegram.CallbackQuery for all methods that accept either chat_id and message_id or inline_message_id

• If relevant:

  • Added new constants at :mod:telegram.constants and shortcuts to them as class variables
  • Link new and existing constants in docstrings instead of hard-coded numbers and strings
  • Add new message types to :attr:telegram.Message.effective_attachment
  • Added new handlers for new update types
  • Add the handlers to the warning loop in the :class:~telegram.ext.ConversationHandler
  • Added new filters for new message (sub)types
  • Added or updated documentation for the changed class(es) and/or method(s)
  • Added the new method(s) to _extbot.py
  • Added or updated bot_methods.rst
  • Updated the Bot API version number in all places: README.rst and README_RAW.rst (including the badge), as well as telegram.constants.BOT_API_VERSION_INFO
  • Added logic for arbitrary callback data in :class:telegram.ext.ExtBot for new methods that either accept a reply_markup in some form or have a return type that is/contains :class:~telegram.Message

[github-actions]

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]

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 of Chat and add only arguments/attributes that ChatFullChatInfo has in addition to Chat. Avoiding to issue deprecation warnings in ChatFullInfo can be done maybe by implementing a helper method Chat._do_warn that ChatFullInfo can override. By subclassing, the return value of get_chat is backward compatible as well and should avoid code duplication for shortcut methods & properties. Document that the Chat base class will be removed in the future.
• On the next api release, we can introduce a new private _ChatBase class that both Chat and ChatFullInfo inherit from.

[harshil21]

• Make ChatFullInfo a subclass of Chat and add only arguments/attributes that ChatFullChatInfo has in addition to Chat. Avoiding to issue deprecation warnings in ChatFullInfo can be done maybe by implementing a helper method Chat._do_warn that ChatFullInfo can override.

what do you think about overriding __getattribute__ to raise the warnings? There are too many attributes to do our previous "make it a property" trick on (DRY principle)?

[Bibo-Joshi]

Thank you very much for the updates! Just two nitpicks

[Bibo-Joshi]

basically LGTM, just two questions out of curiosity :)