{
    "info": {
        "author": "Alex Hall",
        "author_email": "alex.mojaki@gmail.com",
        "bugtrack_url": null,
        "classifiers": [
            "Intended Audience :: Developers",
            "License :: OSI Approved :: MIT License",
            "Operating System :: OS Independent",
            "Programming Language :: Python :: 3.7"
        ],
        "description": "# friendly_states\n\n[![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)\n\nThis 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.\n\nYou can try this README in an interactive notebook in [binder](https://mybinder.org/v2/gh/alexmojaki/friendly_states/master?filepath=README.ipynb).\n\n  * [Introduction](#introduction)\n  * [Basic usage steps](#basic-usage-steps)\n  * [Abstract state classes](#abstract-state-classes)\n  * [BaseState - configuring state storage and changes](#basestate---configuring-state-storage-and-changes)\n  * [State machine metadata](#state-machine-metadata)\n     * [Slugs and labels](#slugs-and-labels)\n  * [Troubleshooting](#troubleshooting)\n  * [Recipes](#recipes)\n     * [Construct and draw a graph](#construct-and-draw-a-graph)\n     * [Creating multiple similar machines](#creating-multiple-similar-machines)\n     * [Dynamically changing the attribute name](#dynamically-changing-the-attribute-name)\n     * [On enter/exit state callbacks](#on-enterexit-state-callbacks)\n  * [Django integration](#django-integration)\n\n## Introduction\n\nHere's a simple example of declaring a state machine:\n\n\n```python\nfrom __future__ import annotations\nfrom friendly_states import AttributeState\n\n\nclass TrafficLightMachine(AttributeState):\n    is_machine = True\n\n    class Summary:\n        Green: [Yellow]\n        Yellow: [Red]\n        Red: [Green]\n\n\nclass Green(TrafficLightMachine):\n    def slow_down(self) -> [Yellow]:\n        print(\"Slowing down...\")\n\n\nclass Yellow(TrafficLightMachine):\n    def stop(self) -> [Red]:\n        print(\"Stop.\")\n\n\nclass Red(TrafficLightMachine):\n    def go(self) -> [Green]:\n        print(\"Go!\")\n\n\nTrafficLightMachine.complete()\n```\n\nThat looks like a lot of code, but it's pretty simple:\n\n1. `TrafficLightMachine` declares the root of a state machine.\n2. There are three states, which are subclasses of the machine: `Green`, `Yellow`, and `Red`.\n3. 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.\n4. `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.\n\nAs 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.\n\nTo 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`:\n\n\n```python\nclass TrafficLight:\n    def __init__(self, state):\n        self.state = state\n\nlight = TrafficLight(Green)\nassert light.state is Green\n```\n\nThe magic happens when making transitions:\n\n\n```python\nGreen(light).slow_down()\nYellow(light).stop()\nassert light.state is Red\n```\n\n    Slowing down...\n    Stop.\n\n\nMaking 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.\nThen you can call methods just like any other class. The state will automatically be changed based on the method's return annotation.\n\nWhy 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.\n\nCompare 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.\n\nBy 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.\n\n[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`.\n\n## Basic usage steps\n\n1) Ensure that you are using Python 3.7+.\n\n2) Install this library with `pip install friendly_states`.\n\n3) Add the line `from __future__ import annotations` at the top of the file where you define your state machine.\n\n4) 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:\n\n\n```python\nfrom __future__ import annotations\nfrom friendly_states import AttributeState\n    \nclass MyMachine(AttributeState):\n    is_machine = True\n    \n    class Summary:\n        Waiting: [Doing, Finished]\n        Doing: [Checking, Finished]\n        Checking: [Finished]\n        Finished: []\n\n```\n\nDeclaring a summary is optional, but highly recommended. The class must be named `Summary`.\nIt should declare the name of every state your machine will have, \neach annotated with a list of every state that can be reached directly from that state by any transition.\n   \nWhen 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:\n\n\n```python\ntry:\n    MyMachine.complete()\nexcept Exception as e:\n    print(e)\n```\n\n    \n    Missing states:\n    \n    class Waiting(MyMachine):\n        def to_doing(self) -> [Doing]:\n            pass\n    \n        def to_finished(self) -> [Finished]:\n            pass\n    \n    \n    class Doing(MyMachine):\n        def to_checking(self) -> [Checking]:\n            pass\n    \n        def to_finished(self) -> [Finished]:\n            pass\n    \n    \n    class Checking(MyMachine):\n        def to_finished(self) -> [Finished]:\n            pass\n    \n    \n    class Finished(MyMachine):\n        pass\n    \n    \n    \n\n\nYou 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.\n\n5) Write a class for each state. Make sure you call `.complete()` at the end.\n\n\n```python\nclass Waiting(MyMachine):\n    def start_doing(self) -> [Doing]:\n        print('Starting now!')   \n\n    def skip(self) -> [Finished]:\n        pass   \n\n\nclass Doing(MyMachine):\n    def done(self, result) -> [Checking, Finished]:\n        self.obj.result = result\n        if self.obj.needs_checking():\n            return Checking\n        else:\n            return Finished\n\n\nclass Checking(MyMachine):\n    def check(self) -> [Finished]:\n        print('Looks good!')\n\n\nclass Finished(MyMachine):\n    pass\n\n\nMyMachine.complete()\n```\n\nState 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.\n\nA 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:\n\n```python\nclass Waiting(MyMachine):\n    def start_doing(self) -> [Doing]:\n```\n\nmeans that `start_doing` is a transition from the state `Waiting` to the state `Doing`, and calling that method will change the state.\n\nThe transition `Doing.done` demonstrates several interesting things:\n\n- 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.\n- Transitions are just like normal methods and can accept whatever arguments you want.\n- 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.\n\n6) The machine doesn't store the state itself, make a different class for that:\n\n\n```python\nclass Task:\n    def __init__(self):\n        self.state = Waiting\n        self.result = None\n    \n    def needs_checking(self):\n        return self.result < 5\n\n    \ntask = Task()\nassert task.result is None\nassert task.state is Waiting\n```\n\nOur 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.\n\n7) 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`.\n\nConstruct an instance of the correct state class and pass your object:\n\n\n```python\nWaiting(task)\n```\n\n\n\n\n    Waiting(obj=<__main__.Task object at 0x1173677f0>)\n\n\n\nIf you get the current state of a task wrong, that means there's a bug in your code! \nIt will throw an exception before you can even call any transitions:\n\n\n```python\ntry:\n    Doing(task)\nexcept Exception as e:\n    print(e)\n```\n\n    <__main__.Task object at 0x1173677f0> should be in state Doing but is actually in state Waiting\n\n\n8) 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:\n\n\n```python\nWaiting(task).skip()\nassert task.state is Finished\n```\n\nIf 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:\n\n\n```python\ntask = Task()\ntry:\n    Waiting(task).done(3)\nexcept AttributeError as e:\n    print(e)\n```\n\n    'Waiting' object has no attribute 'done'\n\n\nHere are the other 2 possible paths for a task from waiting to finished:\n\n\n```python\ntask = Task()\nWaiting(task).start_doing()\nDoing(task).done(3)\nassert task.result == 3\nChecking(task).check()\nassert task.state is Finished\n```\n\n    Starting now!\n    Looks good!\n\n\n\n```python\ntask = Task()\nWaiting(task).start_doing()\nDoing(task).done(7)\n# The result '7' doesn't need checking\nassert task.state is Finished\n```\n\n    Starting now!\n\n\n## Abstract state classes\n\nSometimes 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:\n\n1. You can't inherit from actual state classes.\n2. Transitions must live in classes that inherit (directly or indirectly) from the machine class.\n3. 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.\n\nHere's an example:\n\n\n```python\nclass TaskMachine2(AttributeState):\n    is_machine = True\n    \n    class Summary:\n        Waiting: [Doing, Finished]\n        Doing: [Finished]\n        Finished: []\n\n            \nclass Unfinished(TaskMachine2):\n    is_abstract = True\n    \n    def finish(self) -> [Finished]:\n        pass\n\n    \nclass Waiting(Unfinished):\n    def start_doing(self) -> [Doing]:\n        pass\n\n\nclass Doing(Unfinished):\n    pass\n\n\nclass Finished(TaskMachine2):\n    pass\n\n\nTaskMachine2.complete()    \n```\n\nHere 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.\n\nIf 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:\n\n\n```python\nimport random\n\nfor i in range(100):\n    task = Task()\n    \n    # Randomly start doing about half the tasks\n    if random.random() < 0.5:\n        Waiting(task).start_doing()\n    \n    # Now the task might be either Waiting or Doing\n    Unfinished(task).finish()\n```\n\nThis will still fail if you try it on a finished task:\n\n\n```python\ntry:\n    Unfinished(task).finish()\nexcept Exception as e:\n    print(e)\n```\n\n    <__main__.Task object at 0x11401cb00> should be in state Unfinished but is actually in state Finished\n\n\nHowever, 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: \n\n\n```python\ntask = Task()\nassert type(Unfinished(task)) is Waiting\n```\n\n## BaseState - configuring state storage and changes\n\nAt 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.\n\nFor example, here is the start of `AttributeState` which we've been using as the base of our machines so far:\n\n```python\nclass AttributeState(BaseState):\n    attr_name = \"state\"\n\n    def get_state(self):\n        return getattr(self.obj, self.attr_name)\n```\n\nYou can declare a different `attr_name` in your machine class to store the state in that attribute of the object.\n\nIf you're storing your state in a dict or similar object, you can instead use `MappingKeyState`, which starts like this:\n\n```python\nclass MappingKeyState(BaseState):\n    key_name = \"state\"\n\n    def get_state(self):\n        return self.obj[self.key_name]\n```\n\nIt can often be useful to override `set_state` to add extra common behaviour when the state changes, e.g:\n\n\n```python\nclass PrintStateChange(AttributeState):\n    def set_state(self, previous_state, new_state):\n        print(f\"Changing {self.obj} from {previous_state} to {new_state}\")\n        super().set_state(previous_state, new_state)\n```\n\n`set_state` is called after the transition method completes.\n\nSo overall, your class hierarchy typically looks something like this:\n\n`BaseState <- AttributeState <- Machine <- Abstract States <- Actual states`\n\n## State machine metadata\n\nMachines, states, and transitions have a bunch of attributes that you can inspect:\n\n\n```python\n# All concrete (not abstract) states in the machine\nassert TaskMachine2.states == {Doing, Finished, Waiting}\n\n# All the transition functions available for this state\nassert Waiting.transitions == {Waiting.finish, Waiting.start_doing}\n\n# The transition functions defined directly on this class, i.e. not inherited\nassert Waiting.direct_transitions == {Waiting.start_doing}\n\n# Possible output states from this transition\nassert Waiting.start_doing.output_states == {Doing}\n\n# All possible output states from this state via any transition\nassert Waiting.output_states == {Doing, Finished}\n\n# Root of the state machine\nassert Waiting.machine is TaskMachine2\n\n# Booleans about the type of class\nassert TaskMachine2.is_machine and not Waiting.is_machine\nassert Waiting.is_state and not Unfinished.is_state\nassert Unfinished.is_abstract and not Waiting.is_abstract\n```\n\n### Slugs and labels\n\nClasses 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.\n\nBy 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.\n\n\n```python\nassert Waiting.slug == \"Waiting\"\nassert TaskMachine2.label == \"Task Machine 2\"\n```\n\n## Troubleshooting\n\nIf things are not working as expected, here are some things to check:\n\n- Check the attributes `machine.states`, `state.transitions`, and `transition.output_states` to see if they look as expected.\n- 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.\n- 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:\n\n```python\n    def start_doing(self) -> Doing:\n```\n\n- 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.\n- 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).\n- Check that you've inherited your classes correctly. All states need to inherit from the machine.\n\n## Recipes\n\nThe API of `friendly_states` is intentionally minimal. Here is how you can do some more complicated things.\n\n### Construct and draw a graph\n\nHere is how to create a graph with the popular library `networkx`:\n\n\n```python\nimport networkx as nx\nmachine = MyMachine\n\nG = nx.DiGraph()\nfor state in machine.states:\n    for output_state in state.output_states:\n        G.add_edge(state, output_state)\n\nprint(G.nodes)\nprint(G.edges)\n```\n\n    [Waiting, Finished, Doing, Checking]\n    [(Waiting, Finished), (Waiting, Doing), (Doing, Finished), (Doing, Checking), (Checking, Finished)]\n\n\nTo draw the graph with `matplotlib`:\n\n\n```python\n%matplotlib inline\nnx.draw(G, with_labels=True, node_color='pink')   \n```\n\n\n![png](README_files/README_44_0.png)\n\n\nTo label each edge requires some more work:\n\n\n```python\nedge_labels = {}\nG = nx.DiGraph()\nfor state in machine.states:\n    for transition in state.transitions:\n        for output_state in transition.output_states:\n            edge = (state, output_state)\n            G.add_edge(*edge)\n            edge_labels[edge] = transition.__name__\n\npos = nx.spring_layout(G)\nnx.draw(G, pos, with_labels=True, node_color='pink')\nnx.draw_networkx_edge_labels(G, pos, edge_labels=edge_labels);\n```\n\n\n![png](README_files/README_46_0.png)\n\n\n### Creating multiple similar machines\n\nSuppose 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:\n\n\n```python\nfrom types import SimpleNamespace\n\ndef machine_factory():\n    class Machine(AttributeState):\n        is_machine = True\n\n    class CommonState1(Machine):\n        def to_common_state_2(self) -> [CommonState2]:\n            pass\n\n    class CommonState2(Machine):\n        pass\n\n    return SimpleNamespace(\n        Machine=Machine,\n        CommonState1=CommonState1,\n        CommonState2=CommonState2,\n    )\n\n\nmachine1 = machine_factory()\n\nclass DifferentState(machine1.Machine):\n    def to_common_state_2(self) -> [machine1.CommonState2]:\n        pass\n\nmachine1.Machine.complete()\n\n@machine1.Machine.check_summary\nclass Summary:\n    CommonState1: [CommonState2]\n    CommonState2: []\n    DifferentState: [CommonState2]\n\n\nmachine2 = machine_factory()\nmachine2.Machine.complete()\n\n@machine2.Machine.check_summary\nclass Summary:\n    CommonState1: [CommonState2]\n    CommonState2: []\n```\n\n### Dynamically changing the attribute name\n\nA 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:\n\n```python\ndef machine_factory(name):\n    class Machine(AttributeState):\n        is_machine = True\n        attr_name = name\n\n    ...\n```\n\nAnother option, which may be useful for more complicated situations, is to subclass `AttributeState` to accept the attribute name on construction:\n\n\n```python\nclass DynamicAttributeState(AttributeState):\n    def __init__(self, obj, attr_name):\n        # override the class attribute\n        self.attr_name = attr_name\n        \n        # must call super *after* because it checks the state\n        # in the attribute with the given name\n        super().__init__(obj)\n\nclass Machine(DynamicAttributeState):\n    is_machine = True\n\nclass Start(Machine):\n    def to_end(self) -> [End]:\n        pass\n\nclass End(Machine):\n    pass\n\nMachine.complete()\n\nthing = SimpleNamespace(state=Start, other_state=Start)\n\nassert thing.state is Start\nassert thing.other_state is Start\n\nStart(thing, \"state\").to_end()\nassert thing.state is End\nassert thing.other_state is Start\n\nStart(thing, \"other_state\").to_end()\nassert thing.state is End\nassert thing.other_state is End\n\n```\n\n### On enter/exit state callbacks\n\nWhenever 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:\n\n\n```python\nclass OnEnterExitMixin:\n    def set_state(self, previous_state, new_state):\n        previous_state(self.obj).on_exit(new_state)\n        super().set_state(previous_state, new_state)\n        new_state(self.obj).on_enter(previous_state)\n\n    def on_exit(self, new_state):\n        pass\n\n    def on_enter(self, previous_state):\n        pass\n```\n\nThen use it as follows:\n\n\n```python\nclass Machine(OnEnterExitMixin, AttributeState):\n    is_machine = True\n\nclass Start(Machine):\n    def end(self) -> [End]:\n        pass\n\nclass End(Machine):\n    def on_enter(self, previous_state):\n        print(f\"Ending from {previous_state}\")\n\nMachine.complete()\n\nthing = SimpleNamespace(state=Start)\nStart(thing).end()\n```\n\n    Ending from Start\n\n\n## Django integration\n\n`friendly_states` can easily be used out of the box with Django. Basic usage looks like this:\n\n```python\nfrom django.db import models\nfrom friendly_states.django import StateField, DjangoState\n\nclass MyMachine(DjangoState):\n    is_machine = True\n    \n# ...\n\nclass MyModel(models.Model):\n    state = StateField(MyMachine)\n```\n\n`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:\n\n```python\nobj = MyModel.objects.create(state=MyState)\nassert obj.state is MyState\nobjects = MyModel.objects.filter(state=MyState)\n```\n\nAll keyword arguments are passed straight to `CharField`, except for `max_length` and `choices` which are ignored, see below.\n\n`DjangoState` will automatically save your model after state transitions. To disable this, set `auto_save = False` on your machine or state classes.\n\n`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.\n\nBecause 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:\n\n```python\nclass MyRenamedState(MyMachine):\n    slug = \"MyState\"\n    ...\n```\n\nSimilarly 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.\n\n`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.\n\n`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.",
        "description_content_type": "text/markdown",
        "docs_url": null,
        "download_url": "",
        "downloads": {
            "last_day": -1,
            "last_month": -1,
            "last_week": -1
        },
        "home_page": "http://github.com/alexmojaki/friendly_states",
        "keywords": "",
        "license": "MIT",
        "maintainer": "",
        "maintainer_email": "",
        "name": "friendly-states",
        "package_url": "https://pypi.org/project/friendly-states/",
        "platform": "",
        "project_url": "https://pypi.org/project/friendly-states/",
        "project_urls": {
            "Homepage": "http://github.com/alexmojaki/friendly_states"
        },
        "release_url": "https://pypi.org/project/friendly-states/0.2.0/",
        "requires_dist": null,
        "requires_python": "",
        "summary": "Declarative, explicit, tool-friendly finite state machines in Python",
        "version": "0.2.0"
    },
    "last_serial": 5916208,
    "releases": {
        "0.1.0": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "9bed9d89a3cc820030fe7da0d9430596",
                    "sha256": "8f97f6fdaf790c56435d038a95c1a1072bf188bedccd5d77f35bf87365b09606"
                },
                "downloads": -1,
                "filename": "friendly_states-0.1.0.tar.gz",
                "has_sig": false,
                "md5_digest": "9bed9d89a3cc820030fe7da0d9430596",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 23515,
                "upload_time": "2019-09-22T16:06:49",
                "url": "https://files.pythonhosted.org/packages/80/19/e5be26d56f62ec281893d1103595e285ad9ba27a58984bc322cb61553940/friendly_states-0.1.0.tar.gz"
            }
        ],
        "0.1.1": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "7d3cf868d3b17f15d80f71cc604113fe",
                    "sha256": "d0a16078aee0135002e05b93109ad13023150fab8c520cbb797b09c42972d4d7"
                },
                "downloads": -1,
                "filename": "friendly_states-0.1.1.tar.gz",
                "has_sig": false,
                "md5_digest": "7d3cf868d3b17f15d80f71cc604113fe",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 23600,
                "upload_time": "2019-09-28T17:06:08",
                "url": "https://files.pythonhosted.org/packages/55/08/18211795787c882a3ec80c357d45f3b04c77dc267b20eafa3c291b8484d8/friendly_states-0.1.1.tar.gz"
            }
        ],
        "0.2.0": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "4ccdda28dd0b512fd74f35fc5e888edf",
                    "sha256": "981be61f82455cbdd8a281f2ea0d068ebceb76002824f984d816369847731eda"
                },
                "downloads": -1,
                "filename": "friendly_states-0.2.0.tar.gz",
                "has_sig": false,
                "md5_digest": "4ccdda28dd0b512fd74f35fc5e888edf",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 24011,
                "upload_time": "2019-10-02T05:41:17",
                "url": "https://files.pythonhosted.org/packages/a9/a4/66accf3e80247c1bbf8e96fcacb159bf07db3d6e28af75ea45085786e81d/friendly_states-0.2.0.tar.gz"
            }
        ]
    },
    "urls": [
        {
            "comment_text": "",
            "digests": {
                "md5": "4ccdda28dd0b512fd74f35fc5e888edf",
                "sha256": "981be61f82455cbdd8a281f2ea0d068ebceb76002824f984d816369847731eda"
            },
            "downloads": -1,
            "filename": "friendly_states-0.2.0.tar.gz",
            "has_sig": false,
            "md5_digest": "4ccdda28dd0b512fd74f35fc5e888edf",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": null,
            "size": 24011,
            "upload_time": "2019-10-02T05:41:17",
            "url": "https://files.pythonhosted.org/packages/a9/a4/66accf3e80247c1bbf8e96fcacb159bf07db3d6e28af75ea45085786e81d/friendly_states-0.2.0.tar.gz"
        }
    ]
}