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
<2009>
2010
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
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|