-
Notifications
You must be signed in to change notification settings - Fork 5.9k
Remove DispatcherHandlerContinue + more unitests for dispatcher #792
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
Conversation
The idea was nice, but it really complicated things for us and for the user. If a user wants to run more than one handler on an update, he can put the handlers in different groups or he can have a single handler. If a user wants to have multiple handlers in the same group which only one of them should run on the update, he should use check_update(). Since we haven't released this code yet, there's no problem with backward compatability.
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.
as ever some small docstring changes.
| def add_handler(self, handler, group=DEFAULT_GROUP): | ||
| """ | ||
| Register a handler. | ||
| """Register a handler. |
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.
I moved all docstrings to a newline after """ in all files. Can you please keep that here?
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.
as discussed, i followed pep8
telegram/ext/dispatcher.py
Outdated
| except situations when :class:`telegram.DispatcherHandlerContinue` or | ||
| :class:`telegram.DispatcherHandlerStop` were raised. | ||
| evaluated for handling an update, but only 0 or 1 handler per group will be used. If | ||
| :class:`telegram.DispatcherHandlerStop` is raised from one of the handler, no further |
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.
one of the handlers
| which handlers were added to the group defines the priority. | ||
| * If :class:`telegram.DispatcherHandlerContinue` was raised, then next handler in the | ||
| same group will be called. | ||
| * If :class:`telegram.DispatcherHandlerStop` was raised, then zero handlers (even |
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.
I think the bullet for DispatcherHandlerStop is still valid in the docstring?
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.
it's kind of duplicate of the paragraph above, don't you think?
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.
maybe yes, but now it looks weird as a bullet list for order with just one bullet
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.
two bullets. see below
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.
two bullets. the code below this patch has a second bullet...
The idea was nice, but it really complicated things for us and for the
user.
If a user wants to run more than one handler on an update, he can put
the handlers in different groups or he can have a single handler.
If a user wants to have multiple handlers in the same group which only
one of them should run on the update, he should use check_update().
Since we haven't released this code yet, there's no problem with
backward compatability.