Make job queue API similar to the dispatcher, add new functionality #307
Conversation
|
Changes Unknown when pulling 6b90ac9 on jobqueue-rework into * on master*. |
…on-telegram-bot into jobqueue-rework
|
Changes Unknown when pulling 8278779 on jobqueue-rework into * on master*. |
|
Assigning to @tsnoam |
|
Changes Unknown when pulling b3142d2 on jobqueue-rework into * on master*. |
|
|
||
| def run(self): | ||
| """Executes the callback function""" | ||
| self.callback(self.job_queue.bot, self) |
There was a problem hiding this comment.
will it be better if it's capable to run a job without being added to a job queue?
There was a problem hiding this comment.
This method is used by the job queue, though of course you can also run it from outside.
There was a problem hiding this comment.
IMHO, Job.run method shouldn't depend on a job queue. Rather, I think bot should become a field in Job class. One possible solution is to specify bot as argument in __init__ method. Or it can simply be a public field that's automatically set when added to a job queue.
At least this makes the tests easier to write, since one does no longer need to add a job to a queue in order to check if this job is valid to run.
There was a problem hiding this comment.
Hmm, you could always write a mock JobQueue, but I see your point. I'll get back to you about that.
There was a problem hiding this comment.
@shouya I changed it so it takes the used bot arg as parameter and forwards it to the callback
| @@ -34,10 +34,15 @@ class CallbackQueryHandler(Handler): | |||
| pass_update_queue (optional[bool]): If the handler should be passed the | |||
| update queue as a keyword argument called ``update_queue``. It can | |||
| be used to insert updates. Default is ``False`` | |||
| pass_job_queue (optional[bool]): If the callback should be passed the job queue as a | |||
| keyword argument called ``job_queue``. It can be used to schedule new jobs. | |||
| Default is ``False`` | |||
| """ | |||
There was a problem hiding this comment.
@jh0ker
I find the whole docstring very confusing. Maybe this need rewrite as well?
example:
When set to true, the callback (what callback? the function just called? soemthing else?) will be passed to the job queue as a keyword argument called ``job_queue``. It can be used to schedule new jobs.
I think similar changes for other arguments are in order
There was a problem hiding this comment.
callback is the first argument to __init__, also you added a to there. It's actually the other way: job_queue is passed to the callback function.
There was a problem hiding this comment.
@jh0ker
just shows you how much I got confused 😉
another thought:
always pass job_queue and update_queue as keyword args
then no documentation is needed here
There was a problem hiding this comment.
I'll change the wording ;)
Always passing it means that all callback functions have to at least accept **kwargs, which they currently don't have to (and I'd like to keep it that way)
| @@ -48,15 +48,21 @@ class RegexHandler(Handler): | |||
| pass_update_queue (optional[bool]): If the handler should be passed the | |||
| update queue as a keyword argument called ``update_queue``. It can | |||
| be used to insert updates. Default is ``False`` | |||
| pass_job_queue (optional[bool]): If the callback should be passed the job queue as a | |||
| keyword argument called ``job_queue``. It can be used to schedule new jobs. | |||
| Default is ``False`` | |||
| """ | |||
There was a problem hiding this comment.
same comment as for callbackqueryhandler.py
Conflicts: README.rst telegram/ext/commandhandler.py telegram/ext/messagehandler.py
Conflicts: tests/test_jobqueue.py
this test was based on timing and assumed that the JobQueue did not have time to start processing the queue before checking the assert. what we really should do is make sure JobQueue does not process anything
- start the jobqueue (by default) during __init__() instead of during put() - protect self._next_peek and self.__tick with a Lock - rename self._start() to self._main_loop() - stop() is now blocking until the event loop thread exits
The
JobQueueAPI has been changed to look similar to the 4.xDispatcherAPIInstead of simply passing a callback function to the
JobQueue.putmethod, you now have to pass aJobobject, which__init__takes now the argumentscallback,intervalandrepeat(these were passed toputbefore).The
Jobclass exposes the boolean propertyenabled, which you can use to pause execution of the job temporarily, and the methodschedule_removal, which marks the job for complete removal from the queue. Note: Because theJobQueueinternally uses aPriorityQueue, the job will remain in the queue until it is at the front of the queue, but it will not be executed again.In addition to the
botargument, callback functions now receive their respectiveJobobject in an argument calledjob.The
JobQueueclass now has ajobsmethod, which returns atupleof all jobs currently in the queue.Under the hood
Instead of continuously checking if any jobs should run, the
JobQueuenow waits until the next job is due. If a new job is added in the meantime, the waiting time is re-calculated as necessary. As a result, theticking_intervalargument has been removed from bothJobQueueandUpdater.