transitions
A lightweight, object-oriented state machine implementation in Python with many extensions. Compatible with Python 2.7+ and 3.0+.
Installation
pip install transitions
... or clone the repo from GitHub and then:
python setup.py install
Table of Contents
- Quickstart
- Non-Quickstart
Quickstart
They say a good example is worth 100 pages of API documentation, a million directives, or a thousand words.
Well, "they" probably lie... but here's an example anyway:
from transitions import Machine
import random
class NarcolepticSuperhero(object):
# Define some states. Most of the time, narcoleptic superheroes are just like
# everyone else. Except for...
states = ['asleep', 'hanging out', 'hungry', 'sweaty', 'saving the world']
def __init__(self, name):
# No anonymous superheroes on my watch! Every narcoleptic superhero gets
# a name. Any name at all. SleepyMan. SlumberGirl. You get the idea.
self.name = name
# What have we accomplished today?
self.kittens_rescued = 0
# Initialize the state machine
self.machine = Machine(model=self, states=NarcolepticSuperhero.states, initial='asleep')
# Add some transitions. We could also define these using a static list of
# dictionaries, as we did with states above, and then pass the list to
# the Machine initializer as the transitions= argument.
# At some point, every superhero must rise and shine.
self.machine.add_transition(trigger='wake_up', source='asleep', dest='hanging out')
# Superheroes need to keep in shape.
self.machine.add_transition('work_out', 'hanging out', 'hungry')
# Those calories won't replenish themselves!
self.machine.add_transition('eat', 'hungry', 'hanging out')
# Superheroes are always on call. ALWAYS. But they're not always
# dressed in work-appropriate clothing.
self.machine.add_transition('distress_call', '*', 'saving the world',
before='change_into_super_secret_costume')
# When they get off work, they're all sweaty and disgusting. But before
# they do anything else, they have to meticulously log their latest
# escapades. Because the legal department says so.
self.machine.add_transition('complete_mission', 'saving the world', 'sweaty',
after='update_journal')
# Sweat is a disorder that can be remedied with water.
# Unless you've had a particularly long day, in which case... bed time!
self.machine.add_transition('clean_up', 'sweaty', 'asleep', conditions=['is_exhausted'])
self.machine.add_transition('clean_up', 'sweaty', 'hanging out')
# Our NarcolepticSuperhero can fall asleep at pretty much any time.
self.machine.add_transition('nap', '*', 'asleep')
def update_journal(self):
""" Dear Diary, today I saved Mr. Whiskers. Again. """
self.kittens_rescued += 1
@property
def is_exhausted(self):
""" Basically a coin toss. """
return random.random() < 0.5
def change_into_super_secret_costume(self):
print("Beauty, eh?")
There, now you've baked a state machine into NarcolepticSuperhero
. Let's take him/her/it out for a spin...
>>> batman = NarcolepticSuperhero("Batman")
>>> batman.state
'asleep'
>>> batman.wake_up()
>>> batman.state
'hanging out'
>>> batman.nap()
>>> batman.state
'asleep'
>>> batman.clean_up()
MachineError: "Can't trigger event clean_up from state asleep!"
>>> batman.wake_up()
>>> batman.work_out()
>>> batman.state
'hungry'
# Batman still hasn't done anything useful...
>>> batman.kittens_rescued
0
# We now take you live to the scene of a horrific kitten entreement...
>>> batman.distress_call()
'Beauty, eh?'
>>> batman.state
'saving the world'
# Back to the crib.
>>> batman.complete_mission()
>>> batman.state
'sweaty'
>>> batman.clean_up()
>>> batman.state
'asleep' # Too tired to shower!
# Another productive day, Alfred.
>>> batman.kittens_rescued
1
While we cannot read the mind of the actual batman, we surely can visualize the current state of our NarcolepticSuperhero
.
Have a look at the Diagrams extensions if you want to know how.
The non-quickstart
A state machine is a model of behavior composed of a finite number of states and transitions between those states. Within each state and transition some action can be performed. A state machine needs to start at some initial state. When using transitions
, a state machine may consist of multiple objects where some (machines) contain definitions for the manipulation of other (models). Below, we will look at some core concepts and how to work with them.
Some key concepts
-
State. A state represents a particular condition or stage in the state machine. It's a distinct mode of behavior or phase in a process.
-
Transition. This is the process or event that causes the state machine to change from one state to another.
-
Model. The actual stateful structure. It's the entity that gets updated during transitions. It may also define actions that will be executed during transitions. For instance, right before a transition or when a state is entered or exited.
-
Machine. This is the entity that manages and controls the model, states, transitions, and actions. It's the conductor that orchestrates the entire process of the state machine.
-
Trigger. This is the event that initiates a transition, the method that sends the signal to start a transition.
-
Action. Specific operation or task that is performed when a certain state is entered, exited, or during a transition. The action is implemented through callbacks, which are functions that get executed when some event happens.
Basic initialization
Getting a state machine up and running is pretty simple. Let's say you have the object lump
(an instance of class Matter
), and you want to manage its states:
class Matter(object):
pass
lump = Matter()
You can initialize a (minimal) working state machine bound to the model lump
like this:
from transitions import Machine
machine = Machine(model=lump, states=['solid', 'liquid', 'gas', 'plasma'], initial='solid')
# Lump now has a new state attribute!
lump.state
>>> 'solid'
An alternative is to not explicitly pass a model to the Machine
initializer:
machine = Machine(states=['solid', 'liquid', 'gas', 'plasma'], initial='solid')
# The machine instance itself now acts as a model
machine.state
>>> 'solid'
Note that this time I did not pass the lump
model as an argument. The first argument passed to Machine
acts as a model. So when I pass something there, all the convenience functions will be added to the object. If no model is provided then the machine
instance itself acts as a model.
When at the beginning I said "minimal", it was because while this state machine is technically operational, it doesn't actually do anything. It starts in the 'solid'
state, but won't ever move into another state, because no transitions are defined... yet!
Let's try again.
# The states
states=['solid', 'liquid', 'gas', 'plasma']
# And some transitions between states. We're lazy, so we'll leave out
# the inverse phase transitions (freezing, condensation, etc.).
transitions = [
{ 'trigger': 'melt', 'source': 'solid', 'dest': 'liquid' },
{ 'trigger': 'evaporate', 'source': 'liquid', 'dest': 'gas' },
{ 'trigger': 'sublimate', 'source': 'solid', 'dest': 'gas' },
{ 'trigger': 'ionize', 'source': 'gas', 'dest': 'plasma' }
]
# Initialize
machine = Machine(lump, states=states, transitions=transitions, initial='liquid')
# Now lump maintains state...
lump.state
>>> 'liquid'
# And that state can change...
# Either calling the shiny new trigger methods
lump.evaporate()
lump.state
>>> 'gas'
# Or by calling the trigger method directly
lump.trigger('ionize')
lump.state
>>> 'plasma'
Notice the shiny new methods attached to the Matter
instance (evaporate()
, ionize()
, etc.).
Each method triggers the corresponding transition.
Transitions can also be triggered dynamically by calling the trigger()
method provided with the name of the transition, as shown above.
More on this in the Triggering a transition section.
States
The soul of any good state machine (and of many bad ones, no doubt) is a set of states. Above, we defined the valid model states by passing a list of strings to the Machine
initializer. But internally, states are actually represented as State
objects.
You can initialize and modify States in a number of ways. Specifically, you can:
- pass a string to the
Machine
initializer giving the name(s) of the state(s), or - directly initialize each new
State
object, or - pass a dictionary with initialization arguments
The following snippets illustrate several ways to achieve the same goal:
# import Machine and State class
from transitions import Machine, State
# Create a list of 3 states to pass to the Machine
# initializer. We can mix types; in this case, we
# pass one State, one string, and one dict.
states = [
State(name='solid'),
'liquid',
{ 'name': 'gas'}
]
machine = Machine(lump, states)
# This alternative example illustrates more explicit
# addition of states and state callbacks, but the net
# result is identical to the above.
machine = Machine(lump)
solid = State('solid')
liquid = State('liquid')
gas = State('gas')
machine.add_states([solid, liquid, gas])
States are initialized once when added to the machine and will persist until they are removed from it. In other words: if you alter the attributes of a state object, this change will NOT be reset the next time you enter that state. Have a look at how to extend state features in case you require some other behaviour.
Callbacks
But just having states and being able to move around between them (transitions) isn't very useful by itself. What if you want to do something, perform some action when you enter or exit a state? This is where callbacks come in.
A State
can also be associated with a list of enter
and exit
callbacks, which are called whenever the state machine enters or leaves that state. You can specify callbacks during initialization by passing them to a State
object constructor, in a state property dictionary, or add them later.
For convenience, whenever a new State
is added to a Machine
, the methods on_enter_«state name»
and on_exit_«state name»
are dynamically created on the Machine (not on the model!), which allow you to dynamically add new enter and exit callbacks later if you need them.
# Our old Matter class, now with a couple of new methods we
# can trigger when entering or exit states.
class Matter(object):
def say_hello(self): print("hello, new state!")
def say_goodbye(self): print("goodbye, old state!")
lump = Matter()
# Same states as above, but now we give StateA an exit callback
states = [
State(name='solid', on_exit=['say_goodbye']),
'liquid',
{ 'name': 'gas', 'on_exit': ['say_goodbye']}
]
machine = Machine(lump, states=states)
machine.add_transition('sublimate', 'solid', 'gas')
# Callbacks can also be added after initialization using
# the dynamically added on_enter_ and on_exit_ methods.
# Note that the initial call to add the callback is made
# on the Machine and not on the model.
machine.on_enter_gas('say_hello')
# Test out the callbacks...
machine.set_state('solid')
lump.sublimate()
>>> 'goodbye, old state!'
>>> 'hello, new state!'
Note that on_enter_«state name»
callback will not fire when a Machine is first initialized. For example if you have an on_enter_A()
callback defined, and initialize the Machine
with initial='A'
, on_enter_A()
will not be fired until the next time you enter state A
. (If you need to make sure on_enter_A()
fires at initialization, you can simply create a dummy initial state and then explicitly call to_A()
inside the __init__
method.)
In addition to passing in callbacks when initializing a State
, or adding them dynamically, it's also possible to define callbacks in the model class itself, which may increase code clarity. For example:
class Matter(object):
def say_hello(self): print("hello, new state!")
def say_goodbye(self): print("goodbye, old state!")
def on_enter_A(self): print("We've just entered state A!")
lump = Matter()
machine = Machine(lump, states=['A', 'B', 'C'])
Now, any time lump
transitions to state A
, the on_enter_A()
method defined in the Matter
class will fire.
You can make use of on_final
callbacks which will be triggered when a state with final=True
is entered.
from transitions import Machine, State
states =