Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Add high level method and bound method for setting slow mode #325
Conversation
| def set_chat_slowmode( | ||
| self, | ||
| chat_id: Union[int, str], | ||
| seconds: int |
JosXa
Dec 22, 2019
Contributor
Disregarding the mtproto naming, one could think about renaming this parameter to duration or for_seconds to be more precise.
Disregarding the mtproto naming, one could think about renaming this parameter to duration or for_seconds to be more precise.
JosXa
Dec 22, 2019
Contributor
Also, it might be Optional[int] if we allow passing None.
Also, it might be Optional[int] if we allow passing None.
| seconds: int | ||
| ) -> bool: | ||
| """Set the slow mode in a supergroup. If it is enabled, users can only send one message in the specified time. | ||
| Valid numbers of seconds are: 0 (disabled), 10, 30, 60, 300, 900, 3600 |
JosXa
Dec 22, 2019
Contributor
As the values for this parameter are restricted to a number of choices, maybe it would make sense to abstract them into an enumeration so that users of autocompletion can immediately see the allowed values without concerning the documentation. Of course using the enum should be optional, meaning that if we use an IntEnum it should also be possible to pass an int. However, naming in Python is quite restrictive and class member symbols cannot start with numeric characters...
The only things I could come up with were
class SlowModeDuration(IntEnum):
_10s = 10
_30s = 30
_60s = 60
_300s = 300
_900s = 900
_3600s = 3600
and
class SlowModeDurationSeconds(IntEnum):
ten_seconds = 10
thirty_seconds = 30
one_minute = 60
five_minutes = 300
fifteen_minutes = 900
one_hour = 3600
neither of which I'm particularly fond of.
Maybe someone else has an idea...
As the values for this parameter are restricted to a number of choices, maybe it would make sense to abstract them into an enumeration so that users of autocompletion can immediately see the allowed values without concerning the documentation. Of course using the enum should be optional, meaning that if we use an IntEnum it should also be possible to pass an int. However, naming in Python is quite restrictive and class member symbols cannot start with numeric characters...
The only things I could come up with were
class SlowModeDuration(IntEnum):
_10s = 10
_30s = 30
_60s = 60
_300s = 300
_900s = 900
_3600s = 3600
and
class SlowModeDurationSeconds(IntEnum):
ten_seconds = 10
thirty_seconds = 30
one_minute = 60
five_minutes = 300
fifteen_minutes = 900
one_hour = 3600
neither of which I'm particularly fond of.
Maybe someone else has an idea...
delivrance
Jul 8, 2020
Member
Enums are definitely a good idea. The main reason they are not used already is for consistency with other parts in the library. We need quite a lot of enums, each dedicated to a specific part (chat actions, chat member filters, slowmo durations, etc...). This should be tracked in a whole new issue.
Enums are definitely a good idea. The main reason they are not used already is for consistency with other parts in the library. We need quite a lot of enums, each dedicated to a specific part (chat actions, chat member filters, slowmo durations, etc...). This should be tracked in a whole new issue.
| chat_id (``int`` | ``str``): | ||
| Unique identifier (int) or username (str) of the target chat. | ||
| seconds (``int``): |
JosXa
Dec 22, 2019
Contributor
This should definitely be extended to also allow a None value, which will be equivalent to passing 0 in order to be consistent with the rest of the library.
Don't forget to update the type annotation to be Optional[int].
This should definitely be extended to also allow a None value, which will be equivalent to passing 0 in order to be consistent with the rest of the library.
Don't forget to update the type annotation to be Optional[int].
|
Thanks for your suggestions! I just scrolled through the commits and saw that after I created this PR, a high-level method was implemented already (d71d968) That one also calls the parameter Maybe I better close this PR and create a new one to make the (now) existing method accept |
No description provided.