Simple support for nesting ConversationHandlers#1153
Simple support for nesting ConversationHandlers#1153syntx wants to merge 2 commits intopython-telegram-bot:masterfrom
Conversation
00d3d24 to
4981c4e
Compare
|
Hi @syntx I'm not really seeing how this structure would go down. It's also missing tests. Can you please add tests for expected and failing bahavior? They will be needed for the PR anyway and it might help me understand what this is supposed to do. Pieter |
…d nesting test in test_conversationhandler.py
|
Hi @Eldinnie, I've added a new test in test_conversationhandler.py (test_nested_conversation_handler). |
|
Just wanna say, nice solution a problem that came up a couple times already. I never thought it was worth it implementing something cause there didn't seem to be a neat solution, but i think this is good. Even allows you to go up the conversation handler tree arbitrarily high, which is even better. If we have a bit more documentation and an example for this, I'd approve this PR. Oh and there's a couple |
Allowed ConversationHandler to possibly return a value from its handle_update method
Useful for allowing ConversationHandler to be nested in another ConversationHandler (see #405).
This solution was inspired by transitions library's implementation of Hierarchical State Machines (HSM) (see the 'remap' keyword).
With this change it's now possible to return arbitrary state names in the nested ConversationHandler as long as the state name is mapped to an external ConversationHandler state (e.g. you can have your callback functions return SUCCESS, FAILURE, CANCELED etc. as you wish. You can also map ConversationHandler.END on one or both ends).