Closed GoogleCodeExporter closed 9 years ago
This is my reason not having these types in the beginning. Python only has
float/int/string as basic types. There is little meaning, to me, to support
those different width integers. Moreover channel access protocol makes no
difference between signed and unsigned numbers.
I am not against to support more types but I want to be careful not to cause
confusion to Python programmers.
Do you have any use cases when these are necessary?
Original comment by xiaoqian...@gmail.com
on 30 Jul 2013 at 7:36
This is coming from a case where I am mimicking a record and attempting to keep
all of the types the same. For example, a motor's "motor is moving" field
.MOVN, is a short:
$ cainfo IOC:m1.MOVN
IOC:m1.MOVN
State: connected
Host: 10.0.0.2:5064
Access: read, no write
Native data type: DBF_SHORT
Request type: DBR_SHORT
Element count: 1
I can understand your reasoning from the Python user's standpoint. I'm
perfectly OK with modifying it on my end for my purposes.
Original comment by kenneth....@gmail.com
on 30 Jul 2013 at 2:43
For the completeness I have added 'short' type as cas.aitEnumInt16 in commit
54baa32625b6.
Now the data type supported are DBF_CHAR DBF_SHORT DBF_ENUM, DBF_LONG,
DBF_DOUBLE.
Unsigned numbers are deliberately left out because channel access makes no
difference of it.
Original comment by xiaoqian...@gmail.com
on 9 Oct 2013 at 2:48
Original comment by xiaoqian...@gmail.com
on 9 Oct 2013 at 2:49
Thanks for updating this. I found one small related issue so far:
_checkAlarm() doesn't check for the short, so it returns None, subsequently
nameOf crashes since None isn't in the list of severities (not that it should
be, either):
113 logging.getLogger('pcaspy.Driver.setParam')\
114 .debug('%s: %s %s %s', reason, value, Alarm.nameOf(alarm),
Severity.nameOf(severity))
Original comment by kenneth....@gmail.com
on 17 Oct 2013 at 8:28
Original issue reported on code.google.com by
kenneth....@gmail.com
on 23 Jul 2013 at 6:46