Member

• renames ChatMember.CREATOR to OWNER since for some reason that's what TG named it even though the type is 'creator' …
• and also ChatMember.KICKED -> ChatMember.BANNED
• for classes where we didn't hard code the type, try to resolve the type to the appropriate enum

Checklist for PRs

• Added .. versionadded:: version, .. versionchanged:: version or .. deprecated:: version to the docstrings for user facing changes (for methods/class descriptions, arguments and attributes)
• Created new or adapted existing unit tests
• Added myself alphabetically to AUTHORS.rst (optional)
• Added new classes & modules to the docs

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

• New classes:

  • Added self._id_attrs and corresponding documentation
  • __init__ accepts **_kwargs

• Added new shortcuts:

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

• If relevant:

  • Added new constants at telegram.constants and shortcuts to them as class variables
  • Added new handlers for new update types
  • Added new filters for new message (sub)types
  • Added or updated documentation for the changed class(es) and/or method(s)
  • 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
  • Added logic for arbitrary callback data in tg.ext.Bot for new methods that either accept a reply_markup in some form or have a return type that is/contains telegram.Message

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Member Author

The tests fail, because:

• enum members have an attribute __objclass__ which contains class such that inspect works correctly - see https://bugs.python.org/issue19263
• BP.replace/insert_bot doesn't handle types, so a warning is raised and the test fails

Note that the warning will also be issued when persisting other objects that use the new enum constants, e.g. InlineQueryResult* or Poll - it just didn't show yet. Having a warning raised by the classes PTB ships seems subobtimal. But so does special casing for enums … I see different options here:

• we're okay with the warning and go ahead with this
• we're not okay with the warning and don't use the enum members as constants
• we're not okay with the warning and add special casing for enums to replace/insert
• we postpone until we've had a more general discussion on replace/insert_bot

TBH I'm somewhat in favor of the last 😄

Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look fine. Do you want to apply this to the other enums like BotCommandScope too?

TBH I'm somewhat in favor of the last 😄

yep, we can we defer this for now.

Member Author

For those types of classes we have hard-coded the type, e.g.

Poll, Chat and MessageEntity were the only classes with a type attribute that don't have a subclass for every type …

Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

)