Argonne National Laboratory

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  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 
<== Date ==> <== Thread ==>

Subject: Re: EPICS Python client application survey
From: Benjamin Franksen <benjamin.franksen@bessy.de>
To: tech-talk@aps.anl.gov
Date: Wed, 30 Sep 2009 18:30:26 +0200
On Wednesday 30 September 2009, Matt Newville wrote:
> 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.

It /is/ a difference to the server whether you request DBR_SHORT, DBR_INT, 
or DBR_LONG. These will trigger different conversion routines, and thus 
might give different results.

> The DBR_ type for a
> channel is an implementation detail that is important in C, but not in
> Python.

If it is not important in Python, then why should it be important in C?

> One should be able to create a channel/PV in Python without
> knowing its underlying type.

Yes, but field type is different from request type!

You /don't/ want to use the native (field) type for all queries, for 
instance overlong string fields might actually be implemented in the 
database as a DBF_CHAR array. Requesting the native type will be wrong, in 
this case. OTOH, a DBF_CHAR array might also be meant as a vector of 8-bit 
numbers. The client program must know and choose the correct interpretation 
by chosing the correct request type.

I think it is a very good idea to map the /complete/ C API to a low-level 
python CA lib.

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

Of course, but is a totally different matter as we can easily arrange that 
there is an exact one-to-one mapping between objects and IDs. With request 
types this is not the case as demonstrated above.

Cheers
Ben

Replies:
Re: EPICS Python client application survey Andrew Johnson
References:
Re: EPICS Python client application survey Matt Newville

Navigate by Date:
Prev: Re: EPICS Python client application survey Shen, Guobao
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 
Navigate by Thread:
Prev: RE: EPICS Python client application survey Wang Xiaoqiang
Next: Re: EPICS Python client application survey Andrew Johnson
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 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·