You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description, motivation and use case
The magnet API already has separate holders for simple magnets, combined-function magnets, and serialized magnets. The original holder proposal also calls for convenient navigation from magnets, including access to combined-function magnets and named magnet families.
Users should not need to know the internal holder layout when inspecting a configured magnet family interactively.
Proposed solution
Extend the public magnet collection API:
Add magnets.get_cfm() to return all combined-function magnets as a CombinedFunctionMagnetArray.
Add dynamic attribute access for configured magnet-array names when the name is a valid Python identifier, for example magnets.QuadForTune.
Keep combined_function_magnet, combined_function_magnets, and the serialized-magnet holders as supported explicit APIs.
Dynamic lookup must raise AttributeError for unknown names and must not shadow concrete holder methods or attributes.
Describe alternatives you've considered
Keeping only separate CFM holders is explicit but makes the public API diverge from the navigation proposed in #199. Replacing the existing holders with one heterogeneous collection would reduce type safety and break callers that rely on typed arrays.
MagnetsHolder already returns MagnetArray objects and supports slicing and wildcard filtering. MagnetArray also supports its existing magnet-specific model_name filtering through get_model_name(), for example sr.live.magnets.get()["model_name:*-H"]. This issue adds the missing CFM entry point and ergonomic configured-family lookup without changing existing holder names.
Activity
Complete magnet holder navigation (#373)
Merge pull request #426 from python-accelerator-middle-layer/373-feat…
Complete magnet holder navigation (#373)