Metadata-Version: 2.1
Name: friendly-states
Version: 0.2.0
Summary: Declarative, explicit, tool-friendly finite state machines in Python
Home-page: http://github.com/alexmojaki/friendly_states
Author: Alex Hall
Author-email: alex.mojaki@gmail.com
License: MIT
Description: 
        # friendly_states
        
        [![Build Status](https://travis-ci.org/alexmojaki/friendly_states.svg?branch=master)](https://travis-ci.org/alexmojaki/friendly_states) [![Coverage Status](https://coveralls.io/repos/github/alexmojaki/friendly_states/badge.svg?branch=master)](https://coveralls.io/github/alexmojaki/friendly_states?branch=master) [![Binder](https://mybinder.org/badge_logo.svg)](https://mybinder.org/v2/gh/alexmojaki/friendly_states/master?filepath=README.ipynb)
        
        This is a Python library for writing finite state machines in a way that's easy to read and prevents mistakes with the help of standard linters and IDEs.
        
        You can try this README in an interactive notebook in [binder](https://mybinder.org/v2/gh/alexmojaki/friendly_states/master?filepath=README.ipynb).
        
          * [Introduction](#introduction)
          * [Basic usage steps](#basic-usage-steps)
          * [Abstract state classes](#abstract-state-classes)
          * [BaseState - configuring state storage and changes](#basestate---configuring-state-storage-and-changes)
          * [State machine metadata](#state-machine-metadata)
             * [Slugs and labels](#slugs-and-labels)
          * [Troubleshooting](#troubleshooting)
          * [Recipes](#recipes)
             * [Construct and draw a graph](#construct-and-draw-a-graph)
             * [Creating multiple similar machines](#creating-multiple-similar-machines)
             * [Dynamically changing the attribute name](#dynamically-changing-the-attribute-name)
             * [On enter/exit state callbacks](#on-enterexit-state-callbacks)
          * [Django integration](#django-integration)
        
        ## Introduction
        
        Here's a simple example of declaring a state machine:
        
        
        ```python
        from __future__ import annotations
        from friendly_states import AttributeState
        
        
        class TrafficLightMachine(AttributeState):
            is_machine = True
        
            class Summary:
                Green: [Yellow]
                Yellow: [Red]
                Red: [Green]
        
        
        class Green(TrafficLightMachine):
            def slow_down(self) -> [Yellow]:
                print("Slowing down...")
        
        
        class Yellow(TrafficLightMachine):
            def stop(self) -> [Red]:
                print("Stop.")
        
        
        class Red(TrafficLightMachine):
            def go(self) -> [Green]:
                print("Go!")
        
        
        TrafficLightMachine.complete()
        ```
        
        That looks like a lot of code, but it's pretty simple:
        
        1. `TrafficLightMachine` declares the root of a state machine.
        2. There are three states, which are subclasses of the machine: `Green`, `Yellow`, and `Red`.
        3. Each state declares which transitions it allows to other states using functions with a return annotation (`->`). In this case, each state has one transition to one other state. For example, `Green` can transition to `Yellow` via the `slow_down` method.
        4. `TrafficLightMachine.complete()` makes the machine ready for use and checks that everything is correct. In particular it verifies that the `Summary` class inside `TrafficLightMachine` matches the actual states and transitions declared. Each line of the summary shows all the possible output states from each state.
        
        As we'll see later, a lot of the boilerplate can be generated for you, so don't worry about the effort of writing all those classes.
        
        To use this machine, first we need an object that can store its own state. When using this library, state can be stored however you want, but the way we've declared our machine means it expects an attribute called `state`:
        
        
        ```python
        class TrafficLight:
            def __init__(self, state):
                self.state = state
        
        light = TrafficLight(Green)
        assert light.state is Green
        ```
        
        The magic happens when making transitions:
        
        
        ```python
        Green(light).slow_down()
        Yellow(light).stop()
        assert light.state is Red
        ```
        
            Slowing down...
            Stop.
        
        
        Making an instance of a state class such as `Green(light)` automatically checks that `light` is actually in the `Green` state and raises an exception if it's not.
        Then you can call methods just like any other class. The state will automatically be changed based on the method's return annotation.
        
        Why is this exciting? Because it's obvious to tools which transitions are available to each state. Your IDE can autocomplete `Green(light).slo` for you, and `Green(light).stop()` will be highlighted as an error before you even run the code.
        
        Compare this with the popular library [`transitions`](https://github.com/pytransitions/transitions). States, transitions, and callbacks are all declared using strings, so it's easy to make typos and tools can't help you. In fact you have to stop your tools from warning you about all the attributes it magically generates which you have to use. There's no easy way to see all the transitions or output states from a particular state. Callbacks can be declared far away from transitions.
        
        By contrast, when using `friendly_states`, there are no strings or magic attributes anywhere. Code is always naturally grouped together: all the transitions specific to a state appear inside that class, and logic related to a transition is in that function where you'd expect it.
        
        [Here](https://github.com/alexmojaki/friendly_states/blob/master/transitions_example.py) is the equivalent of the main example in the `transitions` doc implemented using `friendly_states`.
        
        ## Basic usage steps
        
        1) Ensure that you are using Python 3.7+.
        
        2) Install this library with `pip install friendly_states`.
        
        3) Add the line `from __future__ import annotations` at the top of the file where you define your state machine.
        
        4) Declare the root of your state machine by inheriting from the appropriate class (usually `AttributeState`, see the [BaseState](#basestate---configuring-state-storage-and-changes) section) and setting `is_machine = True` in the body, like so:
        
        
        ```python
        from __future__ import annotations
        from friendly_states import AttributeState
            
        class MyMachine(AttributeState):
            is_machine = True
            
            class Summary:
                Waiting: [Doing, Finished]
                Doing: [Checking, Finished]
                Checking: [Finished]
                Finished: []
        
        ```
        
        Declaring a summary is optional, but highly recommended. The class must be named `Summary`.
        It should declare the name of every state your machine will have, 
        each annotated with a list of every state that can be reached directly from that state by any transition.
           
        When you call `MyMachine.complete()`, this summary will be checked, and an exception will be raised explaining the problem if it doesn't match your state classes. In particular if a class is missing the exception will contain generated source code for that class so you can spend less time writing boilerplate. Let's try it now:
        
        
        ```python
        try:
            MyMachine.complete()
        except Exception as e:
            print(e)
        ```
        
            
            Missing states:
            
            class Waiting(MyMachine):
                def to_doing(self) -> [Doing]:
                    pass
            
                def to_finished(self) -> [Finished]:
                    pass
            
            
            class Doing(MyMachine):
                def to_checking(self) -> [Checking]:
                    pass
            
                def to_finished(self) -> [Finished]:
                    pass
            
            
            class Checking(MyMachine):
                def to_finished(self) -> [Finished]:
                    pass
            
            
            class Finished(MyMachine):
                pass
            
            
            
        
        
        You can copy the code above and will have a working state machine matching the summary. It's usually not exactly what you need, but it should save you a lot of time for the next step.
        
        5) Write a class for each state. Make sure you call `.complete()` at the end.
        
        
        ```python
        class Waiting(MyMachine):
            def start_doing(self) -> [Doing]:
                print('Starting now!')   
        
            def skip(self) -> [Finished]:
                pass   
        
        
        class Doing(MyMachine):
            def done(self, result) -> [Checking, Finished]:
                self.obj.result = result
                if self.obj.needs_checking():
                    return Checking
                else:
                    return Finished
        
        
        class Checking(MyMachine):
            def check(self) -> [Finished]:
                print('Looks good!')
        
        
        class Finished(MyMachine):
            pass
        
        
        MyMachine.complete()
        ```
        
        State classes must inherit (directly or indirectly) from the machine class, e.g. `class Waiting(MyMachine):`. A class can have any number of transitions. `Waiting` has two separate transitions, while `Finished` has none, meaning you can't leave that state. It can also have any other methods or attributes which are not transitions, like a normal class.
        
        A transition is any method which has a return annotation (the bit after the `->` in the function definition) which is a list of one or more states that will be the result of this transition. For example, this code:
        
        ```python
        class Waiting(MyMachine):
            def start_doing(self) -> [Doing]:
        ```
        
        means that `start_doing` is a transition from the state `Waiting` to the state `Doing`, and calling that method will change the state.
        
        The transition `Doing.done` demonstrates several interesting things:
        
        - A transition can have multiple possible output states. In that case the method must return one of those states to indicate which one to switch to.
        - Transitions are just like normal methods and can accept whatever arguments you want.
        - States have an attribute `obj` which is the object that was passed to the class when it was constructed. This lets you interact with the object whose state is changing.
        
        6) The machine doesn't store the state itself, make a different class for that:
        
        
        ```python
        class Task:
            def __init__(self):
                self.state = Waiting
                self.result = None
            
            def needs_checking(self):
                return self.result < 5
        
            
        task = Task()
        assert task.result is None
        assert task.state is Waiting
        ```
        
        Our example machine expects to find an attribute called `state` on its objects, as we've provided here. If you have different needs, see the [`BaseState`](#basestate---configuring-state-storage-and-changes) section.
        
        7) To change the state of your object, you first need to know what state it's in right now. Sometimes you'll need to check, but often it'll be obvious in the context of your application. For example, if we have a queue of fresh tasks, any task we pop from that queue will be in state `Waiting`.
        
        Construct an instance of the correct state class and pass your object:
        
        
        ```python
        Waiting(task)
        ```
        
        
        
        
            Waiting(obj=<__main__.Task object at 0x1173677f0>)
        
        
        
        If you get the current state of a task wrong, that means there's a bug in your code! 
        It will throw an exception before you can even call any transitions:
        
        
        ```python
        try:
            Doing(task)
        except Exception as e:
            print(e)
        ```
        
            <__main__.Task object at 0x1173677f0> should be in state Doing but is actually in state Waiting
        
        
        8) Once you have an instance of the correct state, call whatever methods you want on it as usual. If the method is a transition, the state will automatically be changed afterwards:
        
        
        ```python
        Waiting(task).skip()
        assert task.state is Finished
        ```
        
        If you try calling a transition that doesn't exist for a state, the library doesn't even need to do anything. You'll just get the plain Python error you always get when calling a non-existent method, and your IDE/linter will warn you in advance:
        
        
        ```python
        task = Task()
        try:
            Waiting(task).done(3)
        except AttributeError as e:
            print(e)
        ```
        
            'Waiting' object has no attribute 'done'
        
        
        Here are the other 2 possible paths for a task from waiting to finished:
        
        
        ```python
        task = Task()
        Waiting(task).start_doing()
        Doing(task).done(3)
        assert task.result == 3
        Checking(task).check()
        assert task.state is Finished
        ```
        
            Starting now!
            Looks good!
        
        
        
        ```python
        task = Task()
        Waiting(task).start_doing()
        Doing(task).done(7)
        # The result '7' doesn't need checking
        assert task.state is Finished
        ```
        
            Starting now!
        
        
        ## Abstract state classes
        
        Sometimes you will have common behaviour that you need to share between state classes. In that case you can use class inheritance. Here's what you need to be aware of:
        
        1. You can't inherit from actual state classes.
        2. Transitions must live in classes that inherit (directly or indirectly) from the machine class.
        3. Classes that inherit from the machine (and thus can have transitions) but do not represent actual states (and thus can be inherited from) should have `is_abstract = True` in their body.
        
        Here's an example:
        
        
        ```python
        class TaskMachine2(AttributeState):
            is_machine = True
            
            class Summary:
                Waiting: [Doing, Finished]
                Doing: [Finished]
                Finished: []
        
                    
        class Unfinished(TaskMachine2):
            is_abstract = True
            
            def finish(self) -> [Finished]:
                pass
        
            
        class Waiting(Unfinished):
            def start_doing(self) -> [Doing]:
                pass
        
        
        class Doing(Unfinished):
            pass
        
        
        class Finished(TaskMachine2):
            pass
        
        
        TaskMachine2.complete()    
        ```
        
        Here the `Waiting` and `Doing` states are both subclasses of `Unfinished` so they get the `finish` transition for free, and you can see the result of this in the summary.
        
        If you have an object which is in one of these states but you're not sure which, and you'd like to call the `finish` transition, just use the `Unfinished` abstract class:
        
        
        ```python
        import random
        
        for i in range(100):
            task = Task()
            
            # Randomly start doing about half the tasks
            if random.random() < 0.5:
                Waiting(task).start_doing()
            
            # Now the task might be either Waiting or Doing
            Unfinished(task).finish()
        ```
        
        This will still fail if you try it on a finished task:
        
        
        ```python
        try:
            Unfinished(task).finish()
        except Exception as e:
            print(e)
        ```
        
            <__main__.Task object at 0x11401cb00> should be in state Unfinished but is actually in state Finished
        
        
        However, you may want to use methods and attributes in the class representing the actual current state. In particular you might have overridden methods in the concrete state classes and want the correct implementation to run. To allow this, instances of a state automatically change the class to the actual state of the object: 
        
        
        ```python
        task = Task()
        assert type(Unfinished(task)) is Waiting
        ```
        
        ## BaseState - configuring state storage and changes
        
        At the root of all the classes in the library is `BaseState`, which has two abstract methods `get_state` and `set_state`. Subclasses determine how the object stores state and what should happen when it changes.
        
        For example, here is the start of `AttributeState` which we've been using as the base of our machines so far:
        
        ```python
        class AttributeState(BaseState):
            attr_name = "state"
        
            def get_state(self):
                return getattr(self.obj, self.attr_name)
        ```
        
        You can declare a different `attr_name` in your machine class to store the state in that attribute of the object.
        
        If you're storing your state in a dict or similar object, you can instead use `MappingKeyState`, which starts like this:
        
        ```python
        class MappingKeyState(BaseState):
            key_name = "state"
        
            def get_state(self):
                return self.obj[self.key_name]
        ```
        
        It can often be useful to override `set_state` to add extra common behaviour when the state changes, e.g:
        
        
        ```python
        class PrintStateChange(AttributeState):
            def set_state(self, previous_state, new_state):
                print(f"Changing {self.obj} from {previous_state} to {new_state}")
                super().set_state(previous_state, new_state)
        ```
        
        `set_state` is called after the transition method completes.
        
        So overall, your class hierarchy typically looks something like this:
        
        `BaseState <- AttributeState <- Machine <- Abstract States <- Actual states`
        
        ## State machine metadata
        
        Machines, states, and transitions have a bunch of attributes that you can inspect:
        
        
        ```python
        # All concrete (not abstract) states in the machine
        assert TaskMachine2.states == {Doing, Finished, Waiting}
        
        # All the transition functions available for this state
        assert Waiting.transitions == {Waiting.finish, Waiting.start_doing}
        
        # The transition functions defined directly on this class, i.e. not inherited
        assert Waiting.direct_transitions == {Waiting.start_doing}
        
        # Possible output states from this transition
        assert Waiting.start_doing.output_states == {Doing}
        
        # All possible output states from this state via any transition
        assert Waiting.output_states == {Doing, Finished}
        
        # Root of the state machine
        assert Waiting.machine is TaskMachine2
        
        # Booleans about the type of class
        assert TaskMachine2.is_machine and not Waiting.is_machine
        assert Waiting.is_state and not Unfinished.is_state
        assert Unfinished.is_abstract and not Waiting.is_abstract
        ```
        
        ### Slugs and labels
        
        Classes also have `slug` and `label` attributes which are mostly for use by Django but may be useful elsewhere. `slug` is for data storage and `label` is for human display.
        
        By default, `slug` is just the class name, while `label` is the class name with spaces inserted. Both can be overridden by declaring them in the class.
        
        
        ```python
        assert Waiting.slug == "Waiting"
        assert TaskMachine2.label == "Task Machine 2"
        ```
        
        ## Troubleshooting
        
        If things are not working as expected, here are some things to check:
        
        - Check the attributes `machine.states`, `state.transitions`, and `transition.output_states` to see if they look as expected.
        - If you override `set_state`, remember to call `super().set_state(...)`, unless you want to prevent the state from changing or you're subclassing `BaseState` directly.
        - Check that the annotation on your transition is a list, i.e. it starts and ends with `[]`. For example this will not be recognised as a transition:
        
        ```python
            def start_doing(self) -> Doing:
        ```
        
        - If your transition has any decorators, make sure that the decorated function still has the original `__annotations__` attribute. This is usually done by using `functools.wraps` when implementing the decorator.
        - Make sure that the object stores state the way the machine expects. Typically you'll be using `AttributeState` and you should make sure that `attr_name` ("state" by default) is correct. Note that a typical machine expects objects to have just one way of storing state - you can't use the same machine to change state stored in different attributes. To overcome this, see the [recipe 'Dynamically changing the attribute name'](#dynamically-changing-the-attribute-name).
        - Check that you've inherited your classes correctly. All states need to inherit from the machine.
        
        ## Recipes
        
        The API of `friendly_states` is intentionally minimal. Here is how you can do some more complicated things.
        
        ### Construct and draw a graph
        
        Here is how to create a graph with the popular library `networkx`:
        
        
        ```python
        import networkx as nx
        machine = MyMachine
        
        G = nx.DiGraph()
        for state in machine.states:
            for output_state in state.output_states:
                G.add_edge(state, output_state)
        
        print(G.nodes)
        print(G.edges)
        ```
        
            [Waiting, Finished, Doing, Checking]
            [(Waiting, Finished), (Waiting, Doing), (Doing, Finished), (Doing, Checking), (Checking, Finished)]
        
        
        To draw the graph with `matplotlib`:
        
        
        ```python
        %matplotlib inline
        nx.draw(G, with_labels=True, node_color='pink')   
        ```
        
        
        ![png](README_files/README_44_0.png)
        
        
        To label each edge requires some more work:
        
        
        ```python
        edge_labels = {}
        G = nx.DiGraph()
        for state in machine.states:
            for transition in state.transitions:
                for output_state in transition.output_states:
                    edge = (state, output_state)
                    G.add_edge(*edge)
                    edge_labels[edge] = transition.__name__
        
        pos = nx.spring_layout(G)
        nx.draw(G, pos, with_labels=True, node_color='pink')
        nx.draw_networkx_edge_labels(G, pos, edge_labels=edge_labels);
        ```
        
        
        ![png](README_files/README_46_0.png)
        
        
        ### Creating multiple similar machines
        
        Suppose you want to create several machines with similar states and transitions with duplicating code. You may think you can use inheritance somehow, but that won't work, and in fact a machine can't subclass another machine. Instead you must make a function which creates the classes locally. There are many ways this could be one depending on your needs. Here's an example with identical machines except that one has an additional state:
        
        
        ```python
        from types import SimpleNamespace
        
        def machine_factory():
            class Machine(AttributeState):
                is_machine = True
        
            class CommonState1(Machine):
                def to_common_state_2(self) -> [CommonState2]:
                    pass
        
            class CommonState2(Machine):
                pass
        
            return SimpleNamespace(
                Machine=Machine,
                CommonState1=CommonState1,
                CommonState2=CommonState2,
            )
        
        
        machine1 = machine_factory()
        
        class DifferentState(machine1.Machine):
            def to_common_state_2(self) -> [machine1.CommonState2]:
                pass
        
        machine1.Machine.complete()
        
        @machine1.Machine.check_summary
        class Summary:
            CommonState1: [CommonState2]
            CommonState2: []
            DifferentState: [CommonState2]
        
        
        machine2 = machine_factory()
        machine2.Machine.complete()
        
        @machine2.Machine.check_summary
        class Summary:
            CommonState1: [CommonState2]
            CommonState2: []
        ```
        
        ### Dynamically changing the attribute name
        
        A typical `AttributeState` machine can only work with one attribute name. You may need to use the same machine with different object classes that use different attributes. One way is to follow a similar pattern to above with a configurable attribute name:
        
        ```python
        def machine_factory(name):
            class Machine(AttributeState):
                is_machine = True
                attr_name = name
        
            ...
        ```
        
        Another option, which may be useful for more complicated situations, is to subclass `AttributeState` to accept the attribute name on construction:
        
        
        ```python
        class DynamicAttributeState(AttributeState):
            def __init__(self, obj, attr_name):
                # override the class attribute
                self.attr_name = attr_name
                
                # must call super *after* because it checks the state
                # in the attribute with the given name
                super().__init__(obj)
        
        class Machine(DynamicAttributeState):
            is_machine = True
        
        class Start(Machine):
            def to_end(self) -> [End]:
                pass
        
        class End(Machine):
            pass
        
        Machine.complete()
        
        thing = SimpleNamespace(state=Start, other_state=Start)
        
        assert thing.state is Start
        assert thing.other_state is Start
        
        Start(thing, "state").to_end()
        assert thing.state is End
        assert thing.other_state is Start
        
        Start(thing, "other_state").to_end()
        assert thing.state is End
        assert thing.other_state is End
        
        ```
        
        ### On enter/exit state callbacks
        
        Whenever you want to execute some generic logic on every state transition, you should override `set_state`. But if you put all your code in there it may get long and confusing. If you want to group this logic into your state classes whenever a transition enters or exits that state, here's a mixin that you can apply to any machine:
        
        
        ```python
        class OnEnterExitMixin:
            def set_state(self, previous_state, new_state):
                previous_state(self.obj).on_exit(new_state)
                super().set_state(previous_state, new_state)
                new_state(self.obj).on_enter(previous_state)
        
            def on_exit(self, new_state):
                pass
        
            def on_enter(self, previous_state):
                pass
        ```
        
        Then use it as follows:
        
        
        ```python
        class Machine(OnEnterExitMixin, AttributeState):
            is_machine = True
        
        class Start(Machine):
            def end(self) -> [End]:
                pass
        
        class End(Machine):
            def on_enter(self, previous_state):
                print(f"Ending from {previous_state}")
        
        Machine.complete()
        
        thing = SimpleNamespace(state=Start)
        Start(thing).end()
        ```
        
            Ending from Start
        
        
        ## Django integration
        
        `friendly_states` can easily be used out of the box with Django. Basic usage looks like this:
        
        ```python
        from django.db import models
        from friendly_states.django import StateField, DjangoState
        
        class MyMachine(DjangoState):
            is_machine = True
            
        # ...
        
        class MyModel(models.Model):
            state = StateField(MyMachine)
        ```
        
        `StateField` is a `CharField` that stores the `slug` of the current state in the database while letting you use the actual state class objects in all your code, e.g:
        
        ```python
        obj = MyModel.objects.create(state=MyState)
        assert obj.state is MyState
        objects = MyModel.objects.filter(state=MyState)
        ```
        
        All keyword arguments are passed straight to `CharField`, except for `max_length` and `choices` which are ignored, see below.
        
        `DjangoState` will automatically save your model after state transitions. To disable this, set `auto_save = False` on your machine or state classes.
        
        `StateField` will automatically discover its name in the model and set that `attr_name` on the machine, so you don't need to set it. But as usual, beware that you can't use different attribute names for the same machine.
        
        Because the database stores slugs and the slug is the class name by default, if you rename your classes in code and you want existing data to remain valid, you should set the slug to the old class name:
        
        ```python
        class MyRenamedState(MyMachine):
            slug = "MyState"
            ...
        ```
        
        Similarly you mustn't delete a state class if you stop using it as long as your database contains objects in that state, or your code will fail when it tries to work with such an object.
        
        `max_length` is automatically set to the maximum length of all the slugs in the machine. If you want to save space in your database, override the slugs to something shorter.
        
        `choices` is constructed from the `slug` and `label` of every state. To customise how states are displayed in forms etc, override the `label` attribute on the class.
        
Platform: UNKNOWN
Classifier: Intended Audience :: Developers
Classifier: Programming Language :: Python :: 3.7
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: OS Independent
Description-Content-Type: text/markdown
Provides-Extra: tests
