Being able to pipeline operations together seems to be a good fit for coroutines, as mentioned. Or using them to allow for functional programming in an evented architecture
Cheers.

-r

Just to put things straight, I’m not coming out against state machines here. State machines are an important tool – they definitely have their place in software. I’m just presenting co-routines as an alternative for certain cases.

Explicitly specifying state machines is indeed better than just hand coding them from a diagram. There are nice tools out there, like Ragel, that even compile an FSM in some simple DSL to real code (C, C++, Java, Ruby – unfortunately no Python).

http://www.perl.com/pub/a/2004/09/23/fsms.html
This article (written for Perl, but should be easy to understand) demonstrates this. The code just above the “Final Assembly” heading shows a nice example of an explicit state machine. You essentially build a table of [state, condition, action] to define the behaviour.

Another benefit of this style of implementation is that it’s very easy to parse and then give to dot http://www.graphviz.org/ to draw a visual representation of the state machine.

I haven’t tried benchmarking, but in Dave Beazley’s article he came to the conclusion that co-routines are more efficient than the alternative.

BC,

Thanks, this is very interesting.

def traverse(node, func):
  if node is None:
    return
  traverse(node.left)
  func(node)
  traverse(node.right)

I challenge you to write it in a more readable way using explicit stacks instead of recursion.

However, have you looked at the performance implications, if any? It somehow feels like there’d be a price to pay for this.

We normally use data-acquisition devices (PCI cards, from National Instruments) to generate and collect analog and digital signals. These feed a “pipeline” of co-routines. The data processing pipeline can comprise elements like “data averaging”, “output-to-file”, “plotting” and also hardware interactions such as moving linear actuators and GPIB devices. Each one gets a coroutine to control it and manage it’s state.

The data acquisition pipeline node looks like:
@pipeline
def daq_lifecycle(self, output):
....task = daq.initialiseTask()
........task.start()
....try:
........while True:
............output.send((yield))
....finally:
........task.clear()
where the ‘daq’ object represents the PCI card device (wrapped with ctypes).

We also have:
# a little decorator to 'ping' the coroutines first .next() call
def pipeline(func):
....def wrapper(*args, **kw):
........gen = func(*args, **kw)
........gen.next()
........return gen
When new data arrives, it’s is “sent” into the pipeline (in a callback called by the device drivers whenever new data is available). Each node in the pipeline is given an output-coroutine to send it’s data into (except for the terminating node). A full pipeline is built by joining all the required nodes together.

One cool feature is the use of try-finally block. If there’s an exception downstream in the pipeline, it propagates upwards and all the finally blocks execute, restoring the hardware to a safe state. The pipeline can be shutdown manually by “throw”ing an exception into it. The downstream nodes are automatically garbage-collected and all their finally blocks execute, ensuring a safe final state.

Using co-routines means we can drastically reduce the number of state-maintaining attributes on the objects, which simplifies the code and reduces the opportunities for bugs. Also, describing state in terms of point-of-executing in the code makes the state evolution or lifecycle intuitive to understand.

python is awesome.