Conversation
# Conflicts: # telegram/ext/defaults.py # telegram/ext/messagequeue.py # telegram/utils/promise.py
# Conflicts: # telegram/ext/defaults.py # tests/test_defaults.py
# Conflicts: # telegram/ext/messagequeue.py
|
I just realized that the handling of streams this PR introduces is immature. It
Possible ways I see:
For the moment I think I'd be fine with 1., i.e. just not handling it. |
# Conflicts: # telegram/bot.py # telegram/ext/defaults.py # tests/test_bot.py
|
In fact just not supporting context managers will not lead to any major issues for users once #2230 is implemented as can then be replaced by Edit: Went for it. The wiki page needs to be updated anyway, so we can just put a note there. |
There was a problem hiding this comment.
Some more thoughts. Also we should think about #2265
Edit: strictly speaking switching DQ.queue to a delay queue would be breaking
Second Edit: IMO message queue is not well established enough to care about that. The PR currently brings it in a proper state while keeping backwards compatibility as much as possible.
# Conflicts: # telegram/bot.py # telegram/utils/promise.py
|
ready for review now right? GitHub already complains about a merge confilct you might wanna solve that ;P |
|
Closing for now as we'll go a different route (see #2139 for further details). Might still be worth revisiting later. |
Got started on close #2139
Still missing:
MQ.add/remove_delay_queuetelegram.constantsinstead of hardcoding the defaults for max messages per intervalDefaults.delay_queue(_per_method). Forgot about those before marking as ready for review …Just for automatic issue closing:
closes #2015 closes #2012 closes #2035 closes #1369