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.
Example
all_magnets = sr.live.magnets[:]
quad_family = sr.live.magnets.get("QuadForTune")
same_quad_family = sr.live.magnets.QuadForTune
combined_function_magnets = sr.live.magnets.get_cfm()
matching_quadrupoles = sr.live.magnets["Q*D*"]
one_magnet = sr.live.magnet.get("QF1E-C03")
one_magnet.strength.set(0.8)Additional context
Parent issue: ElementHolder API refurbishment #199.
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.
Checklist
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:
magnets.get_cfm()to return all combined-function magnets as aCombinedFunctionMagnetArray.magnets.QuadForTune.combined_function_magnet,combined_function_magnets, and the serialized-magnet holders as supported explicit APIs.Dynamic lookup must raise
AttributeErrorfor 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.
Example
Additional context
Parent issue: ElementHolder API refurbishment #199.
MagnetsHolderalready returnsMagnetArrayobjects and supports slicing and wildcard filtering.MagnetArrayalso supports its existing magnet-specificmodel_namefiltering throughget_model_name(), for examplesr.live.magnets.get()["model_name:*-H"]. This issue adds the missing CFM entry point and ergonomic configured-family lookup without changing existing holder names.Checklist