Repository navigation
ElementHolder API refurbishment #199
Description
Activity
- changed the title
[-]ElementHolder refurbishmenet[/-][+]ElementHolder API refurbishment[/+]on Feb 20, 2026 I have a small question. In the code example you have
sr.rf ... sr.toolIt is planned to have a holder at Accelerator level? Or is it a typo and it should've been
sr.live.rf?Reacted by Jean-Luc PONStypo, you know that I'm the king of the typo :D
I have a small question. In the code example you have
sr.rf ... sr.toolIt is planned to have a holder at Accelerator level? Or is it a typo and it should've been
sr.live.rf?In the end, we might introduce some kind of holder at the Accelerator level to propagate modifications to all other holders affected by the change. The Yellow Pages might be able to handle this.
I updated the first post according to the @TeresiaOlsson suggestion to allow:
sr.live.bpms["BPM*"] # Return all bpms starting with 'BPM' sr.live["BPM*"] # Return all elements starting with 'BPM' (Array dynamically typed)
Why would you do
sr.live.bpms["BPM*"]? That's the same information twice? Personally, I don't entirely understand why we need all of this various holders? Why can't there just be one and then if you for example want to get all the magnets you can find them by type like in pyAT?Also, to me it looks tricky to get
fill_deviceto work together with third-party devices and applications since all the types are currently hardcoded in there. Also feels like a lot of work to maintain it because you need to change in bothcontrolsystem.fill_deviceandsimulation.fill_deviceevery time you add a new type of device.@TeresiaOlsson
I do not see potential problem with fill_device(). ElementHolder will be simply aggregates other Holders.
sr.live.bpms[...]will always return a BPMArray whilesr.live[...]will return a dynamically typed array.
This is important for developers to have the completion working when using IDE that work with not constructed object and need strong typing. This some trade off we have to make otherwise maintaining code with only dynamic typed stuff will be a nightmare.So you mean if I want to change to a facility specific TuneMonitor which includes both transverse and longitudinal tunes like we need for both BESSY II and MLS, I don't need to do any changes in fill_device? If not, what is then the purpose of the
add_betatron_tune_monitor?No change nowhere in pyaml. This is the goal !
You just override the tune monitor with its interface (to do).
Then in the attach method, you can select if you attach to a simulator or to a CS and create locally your own ReadFloatArray for your CS which can be OphydDevice(s) if you want. And you let the super class deal with the simulator attachment.For the time being I'm working on MeasurementTool. I also test OphydAsynch to get the feature I need for dynamic Catalog. OphydAsynch support seems rather efficient. We will see.
Current implementation status:
The typed-holder foundation is now in place:
ElementHolderexposesmagnet/magnets,bpm/bpms, andrf.- Dedicated holders also exist for combined-function and serialized magnets.
magnets.get()andbpms.get()return typed arrays containing all elements.- Named arrays and individual elements can be retrieved through
magnets.get("Family"),bpms.get("Family"),magnet.get("Name"), andbpm.get("Name"). - Typed arrays support slicing, wildcard selection, field-based filtering, and set-like operations (
&,|,-). rf.get(name)is available.rf.frequencyandrf.voltagealready targetDEFAULT_RF_PLANT.
The following parts of the original proposal are not implemented yet:
- A generic
ElementHolder.get(...),ElementHolder[:], andElementHolder["pattern"]API. - Dynamic holder attributes such as
sr.live.magnets.QuadForTune. - A unified
magnets.get_cfm()API. Combined-function magnets are currently exposed through separatecombined_function_magnet(s)holders. - Public
diagnosticandtoolholders, including theirget()APIs and default-object properties. rf.masterclock; the equivalent default RF access currently lives directly underrf.frequencyandrf.voltage.
So the typed collections, typed lookups, filtering, and array operations are implemented. The remaining work is mainly the public ergonomic API proposed in this issue, especially generic element access and the diagnostics/tools namespaces.
Yes this is still in progress. During last maintainer meeting (before my holydays) @theorzr proposed to take it in charge.
But I d'ont know if he has time.
Otherwise I will finish.Reacted by Teresia Olsson, Théo Rozier and gupichon- linked a pull request that will close this issueElementholder api refurbishment #430
on Sep 17, 2026
Description, motivation and use case
Today we have a single
ElementHolderclass that holds everything for a given control mode.The
ElementHoldersuffers from a large number of methods. There is a need for reorganization and the introduction of other holders. Last but not least,ElementHolder.get_all*()orElementHolder.get_*s()function return list while typed array would be suitable. TheElementHolderwill however hold all elements as before.Note that the
getfunction from typed holder will return appropriate typed object or arrays and raise an exception in case of wrong type while the equivalentgeton the base ElementHolder may return random types.Proposed solution
Create new holders such as
Magnet(s)Holder,BPM(s)Holder,RFHolder,DiagnosticHolder,ToolHolderetc and allow access to them trough python properties to allow following writings:This is a non exhaustive list.
Feel free to comment and to propose modifications, I will update this top level post following discussions.