Device and Magnet classes were originally constructed via dictionary loaded from yaml files. The majority of initialisation code was associated with type-checking, and ensuring that the correct information was defined inside the dictionary passed to the constructor.
It was found that Pydantic models can achieve the same effect and do better at type-enforcement/field-enforcement as well as simplifying the code that defines the class architecture for our devices.
Magnet and Device class now use Pydantic models
ControlInformation and Metadata pydantic models define the required information at the base level
PVSet pydantic model define what PV information is required per-device
We now have a MagnetCollection class defined as a pydantic model to perform/manage group-operations on magnets.
Tests
Unit tests for Magnet, MagnetCollection, Device, and magnet reader functions have been redefined to take account of the pydantic model changes.
The user-facing side of these changes now allow us to write code for interfacing with devices like below:
Summary of Changes
Device and Magnet classes were originally constructed via dictionary loaded from yaml files. The majority of initialisation code was associated with type-checking, and ensuring that the correct information was defined inside the dictionary passed to the constructor.
It was found that Pydantic models can achieve the same effect and do better at type-enforcement/field-enforcement as well as simplifying the code that defines the class architecture for our devices.
Tests
The user-facing side of these changes now allow us to write code for interfacing with devices like below:
closes #100