Как текущее состояние управляется в ConversationHandler в python-telegram-api - PullRequest
0 голосов
/ 07 ноября 2018

Я хочу использовать ConversationHandler в моем боте. По крайней мере, для этого потребуется три параметра:

class telegram.ext.ConversationHandler(entry_points, states, fallbacks)

AFAIK, точки входа являются триггерами для обработчика диалога, тогда каждое состояние может выполнять свои собственные обработчики, и на основе определения откатов , если все обработчики из состояния возвращают false, тогда происходит откат .

Итак, обработчики возвращают что-то. Но обработчик - это объект, экземпляр класса.

На основании этого примера , ищем пример для new_alarm_handler.

Так что мои сомнения

  1. Как получается, что обработчики возвращают значение? (Похоже, они возвращают свой результат функции обратного вызова).

  2. Где текущее состояние разговора? Похоже, он недоступен, но является последним результатом последнего выполненного обработчика. Это оно? Если нет, то что мне нужно сделать, чтобы изменить текущее состояние разговора?

  3. Поэтому, когда достигается состояние, выполняется их список обработчиков (значение в словаре states передается как аргумент). Но, будучи списком, он может быть более одного, поэтому может быть более одного возвращаемого состояния. Как это управляется?

1 Ответ

0 голосов
/ 19 апреля 2019

ConversationHandler сохраняет текущий state разговора в диктовке, называемой conversations, а ключом является сущность с именем conversation_key. Это кортеж, который состоит из идентификатора чата, идентификатора пользователя и идентификатора сообщения (некоторые из них могут отсутствовать, это определяется атрибутами per_chat, per_user и per_message bool).

Здесь conversations используется для получения state в методе check_update (поясняется далее):
https://github.com/python-telegram-bot/python-telegram-bot/blob/2cde878d1e5e0bb552aaf41d5ab5df695ec4addb/telegram/ext/conversationhandler.py#L248
Состояние разговора не предназначено для ручного доступа.

Когда пользователь отправляет сообщение боту, Updater получает Update объекты от Telegram и доставляет их на Dispatcher. У Dispatcher есть список зарегистрированных Handler объектов, их методы check_update вызываются в том порядке, в котором они были добавлены. check_update либо возвращает False, либо None, если обновление не должно обрабатываться, либо возвращает некоторый объект, который затем передается методу handle_update.

ConversationHandler наследуется от самого Handler и имеет другие Handler объекты в качестве значений в его states dict. Кроме того, check_update и handle_update перезаписаны. Его check_update получает текущий разговор state (см. Ссылку выше) и вызывает check_update методы всех обработчиков для этого state. Если все они возвращают False, это делает то же самое для обработчиков в списке fallbacks. Если все их проверки также возвращают False, то ничего не происходит.

Если один из обработчиков должен обработать событие, объект, который возвращает check_update, передается методу ConversationHadler handle_update. Он вызывает метод Handler, запущенный *1047*, который, в свою очередь, вызывает функцию обратного вызова, определенную при его создании. Его результатом будет новый state этого разговора в conversations dict.

В соответствии с цепочкой документов ConversationHandler:

To change the state of conversation, the callback function of a handler must return the new state after responding to the user. If it does not return anything (returning ``None`` by default), the state will not change.

...