вот так-то лучше

И че теперь, все переписывать? А оно надо?

необязательно, но лучше переписать до 3.2

А когда  3.0 в pub будет?

Вроде осень март прошел не наступив, но чет обновлений не вижу

Эх паша, мы все п...

она всегда была в pub. не стабильная ещё.

разница баунд фильтра от обычного в:
- с баунд могу делать message_handler(bound_filter=some_data)
- с обычном всё просто, без передачи аргумента   message_handler(filter). Сама проверка настроена в фильтре и её можно будет изменить только в коде

По поводу bind'a : с баундом в принципе понятно. Чтобы использовать как написал выше, его нужно забиндить в filters_factory.
А обычный я могу передавать и как класс handler(CustomFilter), и как аргумент по типу handler(custom_filter), если его забиндЮ?


Я правильно понимаю? Поправьте пожалуйста, если нет

@abstract_x Помню кстати (не могу реплайнуть сообщения, т.к. они почищены 😉 ботом красивым, а зря, столько инфы полезной улетело в помойку), что ты топил за none state,  в том контексте, что когда от пользователя ожидается ввод, чтобы его ответы с клавиатуры не закидывались в обработку ввода.
А почему бы не сделать засунуть в хендлер обработки ввода reply_text filter, куда засовываешь все возможные ответы из button. А потом можно и в функции, обрабатывающей кнопку с клавиатуры при необходимости и наличию стейта его завершать

Может я конечно не в тему вспомнил, или контекст не так воспроизвел, но вдруг кто еще наткнется на это сообщение и идея ему понравится ;)

насколько я сам понял, отличие Filter от BoundFilter в том, что баунд можно задавать именованным аргументом, без необходимости явно его импортировать где-либо. Достаточно забиндить диспетчером, и далее обращаться к фильтру по его ключу через kwargs в регистраторе. Это удобно, например, в случае ReplyButtonFilter:
https://pastebin.com/nzWDkhL1
к которому можно впоследствии обратиться так:
message_handler(reply_button="ButtonText")

В случае с обычным Filter, я расценил его как более широкий аналог лямбда-фильтров, где вся суть стоит в методе проверки check, отдающем boolean. Я стараюсь избегать лямбд, и всегда начинаю с Filter, потом, по-надобности, могу трансформировать в Bound

не совсем понял идею, но если ты пытался понять схему моих обработок, то она такова:
Изначально определяются все возможные варианты ответов пользователя. Среди них может быть:
- Корректный ответ
- Некорректный ответ
- Корректный ответ, но не пройдено какое-то условие
- Кнопка «Отмена»
- Кнопка «В главное меню»
- Команда
и т. д.

Как известно, резолв хэндлеров выполняется в порядке регистрации. Я следую этой схеме течения, и регистрирую в порядке предсказуемости:

- Сначала регистрируются обработчики, фильтры которых нацелены на конкретные ответы (ReplyButtonFilter, команды, и т. п.).
- Затем регистрируется обработчик корректного, ожидаемого ответа. Сюда вешаются все связанные с этим фильтры корректности. Если всё ок, сообщение прошло валидацию, оно уходит в обработчик, который занимается дальнейшей обработкой корректного, проверенного ответа пользователя, так мы не загрязняем хэндлер валидирующим мусором, поручив все проверки предшествующему слою фильтров.
- Далее регистрируются обработчики, которые не прошли вышестоящие проверки, то есть идет обработка некорректного ответа. Если хочется сделать один большой ответ «что-то не так повторите попытку», можно просто присунуть эту регистрацию под корректным обработчиком. В противном случае стоит регистрировать все последующие обработчики в одиночном плане (по одной какой-то комбинации фильтров, под ситуацию), в зависимости от непрошедших вышестоящих фильтров.

У меня тут есть небольшой пример такой регистрации.
Звучит запутанно, да, постарался сжаться в размеры чата)
Скоро будет подробней, надо только подождать и не бухтеть (с)

(всё это идет в рамках одного определенного стейта, то есть ожидания ввода, по ссылке будет понятнее)

🏀 еще один дайс

Только вариантов всего три

Все еще True False None подходят😂

Не, больше

Попал, не попал, застрял. Что ещё?