About return values of action callbacks

[iamgodot]

I read the doc and found it's not very clear about the effects of return values of actions. Now I'm understanding that the returns of before & on actions will be combined as a list when a transition is triggered, yet for after & on_enter & on_exit there's no point to return anything.

Am I getting everything correct? BTW I'd like to refine the docs if needed. Thank you.

[fgmacedo]

Hi @iamgodot , how are you?

Thanks for clarifying this. Yes, this is the current behavior.

My thoughts were that "before" and "on" runs while the transition is executed, and can be perceived as a method call for simple machines. Ex: Imagine that you have pending and completed as states, and an event finish. The on_finish value is returned like you're calling res = sm.finish() if you also implement before_finish a list will be returned.

The other caveat is that since 2.0 we run the state machine on "RTC model" (run to completion), this means that there's an internal queue (more on docs) and you can now call events while processing other events and they will be queued. On RTC, only the main event will get its value returned, and the chained ones will simply return None.

Go ahead, it will really help getting this info clearly on the docs!

Thank you!

[iamgodot]

@fgmacedo Hi, thanks for asking, I'm great.

Actually I was expecting the return value of after_finish would also come up, which seems a bit more intuitive to me. For the current case, I do believe a little more explanation can be very helpful, especially the after is excluded now.

I'll start a pull request for this improvement. As for RTC model, may I take that Non-RTC ones come with opposite logic? Meaning chained events will get expected return values as well?

Appreciate for your quick reply, I think this is a great project :)

[fgmacedo]

I'm not against returning all values, but changing this will require a major version bump because is not backwards compatible (maybe a config parameter?)

Yes, for non-RTC we always collect the results for every event, the downside is that the event processing is chained, so the callbacks ordering can become a mess, specially for the after_transition action.

[iamgodot]

Yes, I'm totally with you. And I'll work on the doc for the current implementation. Need I create an issue for the all-values-returning?

[fgmacedo]

I think that an issue would be better to track back the reasoning about the change.

[iamgodot]

I think that an issue would be better to track back the reasoning about the change.

Sure, it's here #379

[ludoiphone]

Hello, I am French: so I translate with Google.

your state machine interests me

I'm new to the world of python programming for my raspberrypi (4), and I would like to create a state machine for my reversible air conditioning (I created the code in C for arduino).
I would like to have an example of a state machine that manages gpios (input, output), end to the extent possible and if you have a bit of time to give me.
I learn quite quickly.
the link of my machine has state C:

https://wokwi.com/projects/383798765269867521

[iamgodot]

Hello, I am French: so I translate with Google.

your state machine interests me

I'm new to the world of python programming for my raspberrypi (4), and I would like to create a state machine for my reversible air conditioning (I created the code in C for arduino). I would like to have an example of a state machine that manages gpios (input, output), end to the extent possible and if you have a bit of time to give me. I learn quite quickly. the link of my machine has state C:

https://wokwi.com/projects/383798765269867521

Hi, as the OP of this discussion I suggest you open a new one for your question, since I'm closing this one. BTW, what you're doing looks pretty cool so best of luck to that :-)