DiamondLightSource / DiamondLightSource/fastcs
Document convention on Enum key-value naming
- Dominant language
- Python
- Stars
- 6
- Forks
- 8
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 3
Description
See Tom's example here: https://github.com/DiamondLightSource/FastCS/issues/175#issuecomment-3197183789
---
If I create an attribute which uses an Enum that I've created, for example:
```
class DetectorStatus(enum.StrEnum):
IDLE = "Idle"
ERROR = "Error"
WAITING = "Waiting"
RUN_FINISHED = "Run Finished"
TRANSMITTING = "Transmitting"
RUNNING = "Running"
STOPPED = "Stopped"
```
and then
```
trigger_mode = AttrRW(
Enum(TriggerMode),
handler=EnumHandler(TRIGGER_MODE_ENUM_MAPPING, TriggerMode, "timing"),
group=MY_GROUP,
)
```
and then my client (ophyd-async) uses PVI to see what choices this enum can have, it lists the keys of these enums rather than its values. For example, when I try to connect to this device using the following enum in ophyd-async,
```
class DetectorStatus(StrictEnum):
IDLE = "Idle"
ERROR = "Error"
WAITING = "Waiting"
RUN_FINISHED = "Run Finished"
TRANSMITTING = "Transmitting"
RUNNING = "Running"
STOPPED = "Stopped"
```
ophyd-async gives the following error
`TypeError: LAB29-JUNGFRAU:DetectorStatus has choices ('Idle', 'Error', 'Waiting', 'RunFinished', 'Transmitting', 'Running', 'Stopped'), but requested ['IDLE', 'ERROR', 'WAITING', 'RUN_FINISHED', 'TRANSMITTING', 'RUNNING', 'STOPPED'] to be strictly equal to them.`
I would have expected the choices to be the Enum values rather than the keys
## Acceptance Criteria
- FastCS creates PVI for enum signals using the enum values
Contributor guide
Assessment
This issue has not been assessed yet.