Experimental Physics and
Industrial Control System

Matt Newville <[email protected]> · Wed, 30 Sep 2009 09:58:56 -0500

Hi Noboru, Wang, John, Michael, all,

As I've said before, I would be happy to collaborate to come up with a
more uniform approach to using CA with Python.
I agree with Noboru that a two-tier approach is needed.  I'm not so
sure that a 'thin wrapper to all of ca' is crucial.

For example, I don't see significant advantages to having all the C CA
types (DBR_SHORT, DBR_INT, DBR_LONG, etc) exposed to Python at all, as
Python does not distinguish these types, and the difference never
needs to be exposed to the Python programmer.  The DBR_ type for a
channel is an implementation detail that is important in C, but not in
Python.  One should be able to create a channel/PV in Python without
knowing its underlying type.  One should be able to ask for the "extra
information" in a DBR_***_CTRL type (and possibly _STS, _GR types),
but I see no advantage to having 'ca.DBR_LONG' existing in Python.  I
also think there is no point in ever seeing the Channel ID in Python,
as this should always be inside a Channel or PV object.

In addition, exposing CA threads to Python is complicated, and simply
wrapping the C code and telling the Python programmer to deal with the
problem "just like C" seems like a poor choice to me.  The Python
Global Interpreter Lock makes using CA with Python threads perilous:
can a channel/PV in one thread call code in another thread?  Can CA
threads be used with other threading code (GUIs, for example).
Perhaps the Cothreads approach or using subprocess is a better
solution.  I am not sure sure that using preemptive callbacks can
really work in Python, as it would allow a CA C thread to call a
Python function when non-CA Python code is running.....  What happens
if that C thread does not hold the Python GIL?

I also think there are things which are done well at the C level to
help a Python wrapper that would not be part of a 'thin wrapper':
automatically fetching enum string names, a simple "put and wait until
done" method, managing a set of PV connections, and so forth.  These
may seem like "extras" to a C programmer, but they are not to a Python
interface.

Finally, I think documentation is crucial, and find it somewhat
lacking in several of the existing interfaces.

Again, I'd be happy to collaborate on these to make a better and more
uniform python interface.  But I do think there are important details
to be worked out beyond exposing a low-level interface to the C
library.

Cheers,

--Matt Newville <newville at cars.uchicago.edu>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System