DiamondLightSource / DiamondLightSource/fastcs

Document convention on Enum key-value naming

Open
#175 10 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.