Re: EPICS Python client application survey

[Michael Abbott <michael.abbott@diamond.ac.uk>]

On Fri, 2 Oct 2009, Matthieu Bec wrote:
> > Of course.  But Python does not have separate native datatypes for 
> > int, short, long and does not distinguish unsigned and signed integer 
> > types (there are extensions that can make this distinction, mostly 
> > used to pack data for other C libraries).  So, the Python programmer 
> > should never be forced to make the distinction, or even have to know 
> > that it exists.
> > > > The DBR_ type for a channel is an implementation detail that is 
> > > > important in C, but not in Python.
> I think it depends on what you use it for. Consider 'numpy', that has 
> more data types. It's not python, but numpy is quite an essential 
> add-on: I use it so much I would personally not mind see it (at C-API 
> level) used in python-ca.

I agree, numpy is an excellent library.  It is fully integrated into 
cothread.catools: values with more than one point are returned as numpy 
arrays, and in this way I'm able to fully respect the format of the 
returned data.

> > In addition, mixing threads well between C and Python is well known to 
> > be hard and error-prone.  A "complete" API would probably need to 
> > allow "ca_create_context(ca_enable_preemptive_context)". I'm not sure 
> > that even make sense with a language with its own VM.  How is this 
> > *supposed* work in such a case?
> so, I wrote and maintain my own extension (missing from your survey :) 
> that actually does that. Here are the use cases that motivated me:

Oh, I'm sorry, I missed it!  Do you have a link?

> - python used as a shell
> - python UI with your python-toolkit
> - python scripts for 'bash' execution
> 
> > For what it's worth, My own extension and cothreads do not enable 
> > preemptive callbacks, and neither has "native" threads -- my own 
> > simply does not have them at all.
> 
> Does cothreads let you handle those 3 use cases somewhat transparently? 
> One big argument for scripting is that it makes things more 
> straightforward: import the module, do the work.

I believe so; the principal motivation for cothread was to make things 
simple.  Cothreads are easy to use (much easier than native coroutines 
when you may have no idea who's going to give you control next, but you 
need to care), and the channel access integration is very smooth.

There is readline and Qt (both 3 and 4) support integrated into cothread.  
The readline hook is automatically installed so that cothreads can run in 
the background while you're using the interactive Python shell.  The qt 
hook needs to be explicitly installed by calling cothread.iqt().

Integrating cothread with frameworks requires a bit of help from the 
framework: for example, Python provides the readline hook so that cothread 
can borrow control while the user is at the command prompt, and 
integration with Qt requires some mechanism for handing control to and 
fro.  I think I need to write this up!