Context #1100

jsmnbom · 2018-05-03T19:30:27Z

This adds optional support for using context objects instead of all the pass_* in the handlers, as we've talked about a lot in the past.
Motivation is #1080 being seemingly really difficult to implement nicely, and it seems redundant if this got implemented instead (therefore closes #1080).
Not sure if this is exactly how we talked about it, but it seems to implement all that's needed (and as a bonus is 100% backwards compatible!!).

Currently employs a bit of magic to figure out whether to use the old pass_ or the new context. Namely it checks the callback signature to check how many parameters it expects. This is expected to work very well on python >= 3.5 even with decorators. On python < 3.5 it will fail completely if decorators are used, but otherwise work fine.
The user can disable the new functionality by setting use_context=False in a given handler. This is also how it can be manually turned on, in the case of python < 3.5 and decorated callback functions.

tsnoam · 2018-05-03T20:11:08Z

The design discussion is at #1026

jsmnbom · 2018-05-03T20:18:39Z

This is a bit different from that discussion. Mainly that everything is in the context object, but that it acts like a update object, so it's still very convenient for the user. (it also made it much easier to do backwards compat, since it's a different amount of parameters)
The only thing that stood out to be as something we maybe should change is whether to keep groups/groupdict or just have the Match object in there instead.

tsnoam

This looks much better, but I'm afraid we'll still need another pass, hopefully the last. See my comments on the code.

Regarding the "user facing strings" (docstring, deprecation warnings & changelog) - once we'll get a version of the code we're all happy with, I'll add a commit with text (and then you can scrutinize me, lol ;-) )

tsnoam · 2018-05-04T18:59:20Z

telegram/ext/dispatcher.py

-                    handler.handle_update(update, self)
+                for handler in self.handlers[group]:
+                    check = handler.check_update(update)
+                    if check is not None and check is not False:


As discussed, I find this semantics confusing. I prefer something more straight forward:
bool(checkl) evaluates to False - don't handle the update.
bool(check) evaluates to True - handle the update and pass check to handle_update().

However, if you can describe the semantics you chose in simple English and a short phrase (and preferably with docstrings type annotations which makes sense) we can consider your way.

Current behaviour I've described as:
Either ``None`` or ``False`` if the update should not be handled. Otherwise an object that will be passed to :attr:`handle_update` and :attr:`collect_additional_context` when the update gets handled.
This allows both stuff like having CommandHandle.check_update() return message.text.split()[1:] when the update should be handled, and even if there are no args, and it therefore returns [] (a falsey value) it will be handled.
This would advokate for having it just be: Either None to not handle or something else to handle.
But for example in MessageHandler.check_update() I have a return self.filters(message) which determines if the update should be handled.

In conclusion I think we should keep the current logic. Or if you really wanna simplify it, then have it be None to not handle, and everything else gets handled (so the first scenario is still supported).

tsnoam · 2018-05-04T19:01:06Z

telegram/ext/handler.py

@@ -63,12 +78,25 @@ def __init__(self,
                 pass_update_queue=False,
                 pass_job_queue=False,
                 pass_user_data=False,
-                 pass_chat_data=False):
+                 pass_chat_data=False,
+                 use_context=None):


We should put a (very short) deadline for use_context=None and move to an extra deprecation period with use_context=True.

So how long do you propose to have this default to old handler semantics (with deprecation warning obviously) and how long do you think we should keep backward compatibility code once we change the default to the new handler semantics?

I would say 2 months for both?

1 month for each of them seems fine to me... or is that what you're suggesting too?

Maybe: Next major version (so if this is going to be v11, then on v12 we change the default to True, and on v13 or v14 we'll remove the backward compatibility code)

Sounds good to me

(pycharm can be an arse sometimes)

tsnoam · 2018-05-05T13:37:13Z

Replying to @Eldinnie review:
1,1. I agree for CommandHandler to be only for MessagEntity.COMMAND.
Can be in the next PR, but must be before release.

1.2. MessageHandler for everything else. PrefixHandler should be a convenience wrapper on top of it.
Can be in the next PR, but must be before release.

1.3. What is wrong with list of filters? I do not recall that conversation.

2.1. *_updates should still exist in MessageHandler.init() prototype. The implementation detail of using filters is a very good idea.
Can be in the next PR, doesn't have to be before release.

2.2. I would keep RegexHandler, but change it to be a convinient wrapper on top of MessageHandler.

Eldinnie · 2018-05-05T13:41:14Z

1.3 Long time ago the filters argument was supposed to be a list of callables and the handler woud handle the update if any of those would return True In october 2016 the bitwise filters have been added #411 and we've supported both (list of filters and bitwise filters) since then. there's a warning list is deprecated since then: https://github.com/python-telegram-bot/python-telegram-bot/blob/master/telegram/ext/messagehandler.py#L123
I say we remove it now

tsnoam · 2018-05-05T13:44:08Z

1.3. Ok. Removing the filters list is a good idea. But I think that we should have in the migration guide a code snippet demonstrating how to convert a list of filters to bitwise-or filters

JosXa · 2018-05-05T13:52:05Z

Could we please gather up the individual user handlers that do not fit the new callback signature and show a single deprecation warning message to the user in the following fashion:

"TelegramDeprecationWarning: You are currently not using context based handlers. This is being deprecated, and will soon not be possible. Please change your callback function signatures from (bot, update, others...) to (update, context), and create your handlers using use_context=True instead of setting any pass_ parameters. You can set use_context=False to turn this warning off. Please see https://git.io/vpVe8 for more info.

Your following callables are affected by this:
- MessageHandler(whatever_the_user_set_up, pass_bla=True)
- MessageHandler(whatever_the_user_set_up, pass_bla=True)
- MessageHandler(whatever_the_user_set_up, pass_bla=True)
- MessageHandler(whatever_the_user_set_up, pass_bla=True)
- MessageHandler(whatever_the_user_set_up, pass_bla=True)
- MessageHandler(whatever_the_user_set_up, pass_bla=True)
- MessageHandler(whatever_the_user_set_up, pass_bla=True)
- MessageHandler(whatever_the_user_set_up, pass_bla=True)
- ...
"

Might be possible to do this with a little timeout that checks a list of wrongdoings after like 2 seconds or so after the initialization step. Reasoning behind this is that I'm currently being flooded with ~140 warning messages in one of my bigger bots, and we don't want to make a bad impression towards our users with this change but the opposite :)

tsnoam · 2018-05-05T14:03:13Z

@JosXa Lets first see what the actual strings will look like.
As stated on the developers group, I want them to look something like:

<object_name>  is deprecated. See http://...

…ilters themselves

nmlorg · 2018-05-15T07:52:54Z

examples/paymentbot.py

    query = update.shipping_query
    # check the payload, is this from your bot?
    if query.invoice_payload != 'Custom-Payload':
        # answer False pre_checkout_query
-        bot.answer_shipping_query(shipping_query_id=query.id, ok=False,
-                                  error_message="Something went wrong...")
+        query.answer(shipping_query_id=query.id, ok=False,


Remove shipping_query_id=query.id, .

nmlorg · 2018-05-15T07:53:30Z

examples/paymentbot.py

@@ -89,31 +90,33 @@ def shipping_callback(bot, update):
        # an array of LabeledPrice objects
        price_list = [LabeledPrice('B1', 150), LabeledPrice('B2', 200)]
        options.append(ShippingOption('2', 'Shipping Option B', price_list))
-        bot.answer_shipping_query(shipping_query_id=query.id, ok=True,
-                                  shipping_options=options)
+        query.answer(shipping_query_id=query.id, ok=True,


Remove shipping_query_id=query.id, .

nmlorg · 2018-05-15T07:54:17Z

examples/paymentbot.py

    query = update.pre_checkout_query
    # check the payload, is this from your bot?
    if query.invoice_payload != 'Custom-Payload':
        # answer False pre_checkout_query
-        bot.answer_pre_checkout_query(pre_checkout_query_id=query.id, ok=False,
-                                      error_message="Something went wrong...")
+        query.answer(pre_checkout_query_id=query.id, ok=False,


Remove pre_checkout_query_id=query.id, .

nmlorg · 2018-05-15T07:54:46Z

examples/paymentbot.py

    else:
-        bot.answer_pre_checkout_query(pre_checkout_query_id=query.id, ok=True)
+        query.answer(pre_checkout_query_id=query.id, ok=True)


Remove pre_checkout_query_id=query.id, .

nmlorg · 2018-05-15T08:07:03Z

telegram/ext/messagehandler.py

-        optional_args = self.collect_optional_args(dispatcher, update)
-
-        return self.callback(dispatcher.bot, update, **optional_args)
+                if self.filters is None:


self.filters will never be None if it evaluated to True on line 149.

nmlorg · 2018-05-15T08:13:24Z

telegram/ext/jobqueue.py

+                    self.use_context = False
+
+            self._dispatcher = MockDispatcher()
+        self._dispatcher = None


This clobbers lines 50-59, maybe reorder or:

if bot: ... self._dispatcher = MockDispatcher() ! else: ! self._dispatcher = None

jsmnbom · 2018-05-15T10:00:45Z

Thanks for the review @nmlorg :D You're totally right in all the comments :)

This reverts commit 247577b.

This reverts commit f8a17cd

jsmnbom added 8 commits May 3, 2018 23:18

Change handlers so context is supported

3ce9363

Attempt to make parameter "guessing" work on py < 3.5

714d96d

Document use_context in all handlers

32a2453

Add Context to docs

5738f00

Minor fixes to context handling

0580ae3

Add tests for context stuff

bad8f35

Allow the signature check to work on py<3.5 with methods

7e2fb8d

Fix order of operations

d133dd4

tsnoam force-pushed the context branch from 9b0bda4 to d133dd4 Compare May 3, 2018 20:21

Address most issues raised in CR

5bfaca0

JosXa mentioned this pull request May 4, 2018

Integrating chat_data and user_data with respective Objects #1080

Closed

tsnoam requested changes May 4, 2018

View reviewed changes

jsmnbom added 8 commits May 5, 2018 14:43

Make CommandHandler no longer support filter lists

bfec5ea

Fix indent

da26227

(pycharm can be an arse sometimes)

Improve readability in conversationhandler

c450a4e

Make context have Match instead of groups & groupdict

35c07dd

Remove filter list support from messagehandler too

b325cc1

Small fix to StringCommandHandler

945a5ec

More small fixes to handlers

07747f3

Amend CHANGES

a54cfac

Fix tests and fix bugs raised by tests

30712c5

jsmnbom added 2 commits May 5, 2018 16:06

Don't allow users to ignore errors without messing with the warning f…

e87a705

…ilters themselves

Merge branch 'master' into context

c69378f

python-telegram-bot deleted a comment from tsnoam May 11, 2018

python-telegram-bot deleted a comment from Eldinnie May 11, 2018

python-telegram-bot deleted a comment from tsnoam May 11, 2018

Add tests for callbackcontext & for context based callback job

1fb2e6e

Eldinnie approved these changes May 15, 2018

View reviewed changes

nmlorg reviewed May 15, 2018

View reviewed changes

Fix as per review :)

9c4dc3c

jsmnbom merged commit 247577b into master May 21, 2018

Eldinnie deleted the context branch May 21, 2018 22:27

This was referenced May 22, 2018

Handler callback revamp #1026

Closed

ConversationHandler is not thread safe #1029

Closed

Eldinnie mentioned this pull request May 25, 2018

examples: updated timerbot to work with the latest version of the library #1119

Closed

Eldinnie pushed a commit that referenced this pull request May 31, 2018

Revert "Context based callbacks (#1100)"

f8a17cd

This reverts commit 247577b.

jsmnbom added a commit that referenced this pull request Sep 21, 2018

Revert "Revert "Context based callbacks (#1100)""

cf95027

This reverts commit f8a17cd

jsmnbom added this to the V12 milestone Feb 9, 2019

gdalmau mentioned this pull request Sep 16, 2019

Upgrade Updater call to the latest version of python telegram bot package ytturi/MortDeGana_Bot#4

Merged

github-actions bot locked and limited conversation to collaborators Aug 21, 2020

Context #1100

Context #1100

Uh oh!

Conversation

jsmnbom commented May 3, 2018

Uh oh!

tsnoam commented May 3, 2018

Uh oh!

jsmnbom commented May 3, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tsnoam left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jsmnbom May 5, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tsnoam commented May 5, 2018

Uh oh!

Eldinnie commented May 5, 2018

Uh oh!

tsnoam commented May 5, 2018

Uh oh!

JosXa commented May 5, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tsnoam commented May 5, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jsmnbom commented May 15, 2018

Uh oh!

Uh oh!

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

jsmnbom commented May 3, 2018 •

edited

Loading

jsmnbom May 5, 2018 •

edited

Loading

JosXa commented May 5, 2018 •

edited

Loading

tsnoam commented May 5, 2018 •

edited

Loading