Conversation
There was a problem hiding this comment.
Nice change. I thought of Enums too few months back, but dropped it for some reason.
Some changes to be made:
- The
ChatActionandParseMode.rstfiles should be deleted, and fromtelegram.rst(sphinx raises warnings), - There's still
telegram.ChatActionall over the docs, should be updated.
# Conflicts: # examples/errorhandlerbot.py # telegram/__init__.py # telegram/_chat.py # telegram/_chataction.py # telegram/_parsemode.py # telegram/_user.py # tests/test_bot.py
|
@harshil21 what do you think about the two points that I mentioned under "Some more changes that could be made but …"? |
harshil21
left a comment
There was a problem hiding this comment.
what do you think about the two points that I mentioned under "Some more changes that could be made but …"?
I think we should keep both of them the way it is. Makes it slightly easier for the user. It's not immediately obvious that list(constants.UpdateType) is Update.ALL_TYPES
…ve_attachment & helpers.effective_message_type
|
I like the organisation and improved import. I dont like the docs. Is there a way to get sphinx to insert the value of the constants we link to? I would combine this: Either inline link to the constant but write the value there. Or write the import phrase and insert the value in brakets. I understand that we want to push people to use our constants, but if they dont want to for whatever reason, we take away the quick look up. |
|
Valid point @Poolitzer 👍 . A straightforward way would be to do |
# Conflicts: # telegram/_files/inputmedia.py # tests/test_constants.py
|
This was actually a bit easier than I thought :) I addded a new role One thing that come to think of while doing this is that we also could change the type hints of the parameters where you should pass constants. e.g. |
harshil21
left a comment
There was a problem hiding this comment.
another tiny unrelated change
imo it should be as it is, because ultimately the value is actually a string, the user might think that ParseMode is some class they have to know how to initialize etc. Also whenever there's a new API update, and the user wants to use the new value, they'll have to switch back to a string anyway (until PTB updates). Also skimming through that RTD I saw that we should add an |
Hey. I'm aware that we didn't discuss this, but it felt like reasonable change. If you disagree, we can close :D
Key points of this PR:
tg.constantsinto enums. This has the advantage ofParseMode.HTMLinstead ofPARSEMODE_HTML)int/str, so no change there<ParseMode.HTML>, rather than the default behavior of<ParseMode.HTML: 'html'>. This is because the actual value is of little interest and IMO it also encourages users to use the constants rather than plain strings.tg.{ChatAction, ParseMode}were removed in favor oftg.constants.{ChatAction, ParseMode}.Some more changes that could be made but that I didn't make yet because I wasn't sure if we want that:
Update.ALL_TYPES. However, if you agree, I think we can remove them, as now one can just dolist(constants.UpdateType).Chat.{PRIVATE, CHANNEL, …}byChat.TYPES = tg.constants.ChatType.things that should be done in any case:
telegram.ParseModeif Input media subclasses init handling refactor #2573 #2717 is merged before thisInputMedia*typesChecklist for PRs
.. versionadded:: version,.. versionchanged:: versionor.. deprecated:: versionto the docstrings for user facing changes (for methods/class descriptions, arguments and attributes)Breaking changes:
constantsare now enums