Member
Member
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes themself look got to me 👍
- pre-commit is complaining a bit. If you run
pre-commit installlocally, the pre-commit hooks will run before you can commit - We'll need a test to ensure that the warning is issued as expected, i.e. the warning is there, the messages is the expected one and the warning points the user to the line where
context.job_queueis accessed. You can e.g. have a look atTestJobQueue.test_run_dailyfor some inspiration on how that can be done :)
Member
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some stylistic suggestions below.
Also the more likely scenario is when user does application.job_queue.run_* and faces an error. Shouldn't we make that a property to raise this warning as well?
Member
Also the more likely scenario is when user does
application.job_queue.run_*and faces an error. Shouldn't we make that a property to raise this warning as well?
I guess it's hard to say if app.job_queue or context.job_queue is used more … but anyway, making Application.job_queue a property and having it issue a warning just like CallbackContext.job_queue sounds like a nice idea :)
Member
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updates!
-
TestConversationHandler.test_no_running_job_queue_warningcurrently fails b/c it's trying to overrideapp.job_queue. Maybe it's best to build a newApplicationinstance in that test, i.e. something likeif not jq: app = ApplicationBuilder().token(bot.token).job_queue(None)
-
similar for
TestConversationHandler.test_schedule_job_exception: here one would doAB().token(…).job_queue(DictJQ())
Member
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay I'm not sure why Github is not showing me the changes in conversationhandler.py in the files changed tab, but I think you should replace all instances of application.job_queue with application._job_queue to avoid unintentionally raising a warning in user code
Member
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took the liberty to tie up the very last loose ends :) I'm happy now. If harshil is as well, we can merge.
Member
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Bibo-Joshi deleted the raise_warning_when_jobqueue_is_none branch
December 2, 2022 11:08