Finite State Machines with Python Coroutines
Perhaps I&#x27;m missing it, but the only reason I can find in TFA for using coroutines here is that it&#x27;s the most intuitive way of writing this FSM class.<p>Is it really more intuitive than something like:<p><pre><code>    class FSM:
        def __init__(self):
            self.current_state = self._start
            self.stopped = False
        
        def send(self, char):
            self.current_state(char)
        
        def does_match(self):
            if self.stopped:
                return False
            return self.current_state == self._q3

        ...

        def _q2(self, char):
            if char == &#x27;b&#x27;:
                return

            if char == &#x27;c&#x27;
                self.current_state = self._q3

            self.stopped = True

        ...
</code></pre>
(Using names &#x27;send&#x27; etc. from the article just for easier comparison.)<p>This is basically the same except not using co-routines, and I don&#x27;t see what advantage using them brings?<p>Not using them has a clear advantage (IMO) that we don&#x27;t have to initialise each state (`_create_q2()`) - which just seems strange to read, and a recipe for forgetting (&#x27;I just added a state for this, why are we still seeing this error...&#x27;) since it essentially means a state is &#x27;declared&#x27; in init, and defined in a method. But this is Python, and a compiler won&#x27;t complain. Neither will your linter know^ that you should have called that method in `__init__`.<p>^<i>(OK, you _might_ have a check that it&#x27;s used anywhere ever, but there&#x27;s a lot of good reasons for not having that - library code, abstractions, linter not clever enough to work out you have called things in a non-straightforward way, etc.)</i>