Document convention on Enum key-value naming

Open
#175 10 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
42/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
python
Domain
backend

Research direction

Start by tracing how PVI enum signals are generated from AttrRW and EnumHandler, using the DetectorStatus and TriggerMode examples in the issue. Reproduce the mismatch between enum keys and values, then verify that generated PVI choices use the enum values described in the acceptance criteria.

Written by the indexing model from the issue text.

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 <enum 'DetectorStatus'> 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
Dominant language
Python
Stars
6
Forks
8
Avg merge
2d 12h
Merged PRs (30d)
3

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from DiamondLightSource/fastcs

All issues in DiamondLightSource/fastcs

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.