What initially attracted me to cothread was the simple yet powerful API
of catools. It took me a while to appreciate the cooperative threading
aspect. I think this was mainly because it differs from the OS
threading APIs I was used to. Considered from the prospective of a new
programmer without such a bias, I would agree with Michael Abbott that
it is easier to learn.

On 3/12/2012 12:17 PM, Matt Newville wrote:

...

With Python threads it seems to me that the biggest down side of cothread, that there is only one thread of
execution, has much less impact, as Python only ever executes one thread at a time in the interpreter anyway!

To me, this would seem to have very little to do with Channel Access,
and more to do with python's threading implementation. Is that a fair
characterization? If so, should it be a separate python package,
useful outside of the scope of Channel Access?

...
Coding with callbacks requires a continuation style of programming mixed with threading based events when you need
to resynchronise with the original caller. This is definitely harder to write, particularly when exceptions and
error handling need to be taken into account.

I'm not sure I'm following you here. Concrete examples would be nice.

I don't have any examples showing both ways, mostly because with
cothreads I can happily avoid continuation passing.

There are some related examples from the Twisted library's
inlineCallbacks feature. This is the first concise example I could find:

Note that while the syntax and effect are similar, the implementation is
much different (less general, but more portable). It is not saving the
stack, but rather taking advantage of the fact that python generators
are functions with multiple entry points.

...

...
for pvname in list_of_pvnames:
print caget(pvname)

Please consider that catools.caget can accept a list of pvs directly.

R = caget(list_of_pvnames)

This can be combined a FORMAT_* specifier to get metadata as well. Oh,
and it works for a list of PVs with mixed types.