GeezerVison

A thought I had: Since this is such a huge change for something so integral to our project, should we provide a beta version/implementation after we are satisfied with the status and announce it to get people to try it out and provide feedback before we make a first release?

A thought I had: Since this is such a huge change for something so integral to our project, should we provide a beta version/implementation after we are satisfied with the status and announce it to get people to try it out and provide feedback before we make a first release?

That is indeed a very good idea 👍
My thoughts on this are roughly like this:

• the overall change should (hopefully) be such that nothing changes if you just don't use the new states.
• that way we can introduce the refactoring & deprecate the existing CH without braking changes.
• We can mark the status as "public beta feature" and at some point we can say "well, starting with version 25.0, states are now marked as stable".

that way we wouldn't have to do any additional actual beta releases.
If we prefer to have a proper beta release, I'm open to that. We could e.g. do states update on a 23.0bx line that gets only updates for states while other stuff (especially API updates only go into 22.x) . We shouldn't do that for too long IMO, we saw how much effort that takes with v20.
Encouraging people to try out a branch is ofc an easy option.

I dont get the first point, what do you mean with not using new states. In conjunction with ConvHandler? I thought this is supposed to fully replace it. In that case I would like a big announcement at least (maybe also in readme or so).

We might not really need an extra release now that I think of it, just make a big fuss about it before calling it stable and doing the deprecation error warning.

I dont get the first point, what do you mean with not using new states. In conjunction with ConvHandler? I thought this is supposed to fully replace it. In that case I would like a big announcement at least (maybe also in readme or so).

Yes, this is supposed to replace CH. But, since this is acting on a different level than handlers, the conversationhandlerbot.py example will still run as before. We should throw hella-big warnings if states & CH are used in conjunction, true.
All other features that are independent of CH will also all run the same. all keys will always be in state "IDLE".

We might not really need an extra release now that I think of it, just make a big fuss about it before calling it stable and doing the deprecation error warning.

👍

Ah yes you mean in the transition period alright. Okay so lets do a release when we are happy and announce that its there and see if we get feedback, and then do a deprecation later. Perfect.

I'm not sure if this is the right place to mention this but:

Is there any plans or ongoing work for a declarative but an extensible (e.g. with hooks) FSM syntax? like State1 ---(on some input or trigger) ---> State2 (produce or calculate some output or perform a set of actions) ?

I have a fairly complex stateful bot in PTB (and ConversationHandler) and have written a very rudimentary function that parses a generically defined (but limited) transition table (declarative) and performs the transitions given the inputs and also produces some (a set of) outputs or actions.

I did it for a subset of states (relatively simple logic) in my application, because in the current PTB framework adding states and extending the FSM logic is somewhat a pain. Code re-usability was another consideration (e.g. several states might want to transition to a very specific state and so using a common transition function or hook for setting up the UI and then entering that state is useful for code reuse).

A declarative approach to complex FSM logic specification would both accelerate and simplify development, IMHO.