EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: EPICS Python client application survey
From: Matthieu Bec <[email protected]>
To: Matt Newville <[email protected]>
Cc: [email protected]
Date: Fri, 02 Oct 2009 22:30:37 -0400

Hi Matt,

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.

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:

- python used as a shell
I found ca_enable_preemptive_context + python GIL work well.
early implementation (R3.12? when ca was not thread safe) used hooks to libreadline and handle the ca background polling.

- python UI with your python-toolkit
mixing X and threads seems extremely difficult, the simplicity one might be seeking with python script is lost. Here instead, I have a (gtk) wrapper that starts ca_disable_preemptive_context and handles ca polling with a glib.timeout_add(...)

- 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.

Matthieu



--
Matthieu Bec              Gemini Observatory
Tel: +56 51 205785        c/o AURA, Casilla 603
Fax: +56 51 205650        La Serena, Chile

Replies:
Re: EPICS Python client application survey Matt Newville
Re: EPICS Python client application survey Michael Abbott
References:
Re: EPICS Python client application survey Matt Newville

Navigate by Date:
Prev: Re: state notation code flags Patrick Thomas
Next: RE: state notation code flags Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: EPICS Python client application survey Matt Newville
Next: Re: EPICS Python client application survey Matt Newville
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024