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
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.
- Re: EPICS Python client application survey Andrew Johnson
- Re: EPICS Python client application survey Matt Newville
- Navigate by Date:
Re: EPICS Python client application survey Shen, Guobao
Re: EPICS Python client application survey Matt Newville
- Navigate by Thread:
RE: EPICS Python client application survey Wang Xiaoqiang
Re: EPICS Python client application survey Andrew Johnson