Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System