LHCb Core Software Meeting, 13 Dec /5 Proposal for Reflex Dictionaries in LHCb E. Rodrigues, NIKHEF Python – C++ bindings Python knows about our C++ objects via dictionaries All is nicely done “behind the scenes” … Dictionaries All our XML-defined event classes have the corresponding dictionaries built automatically Other (event) classes defined in.h &.cpp needed some extra “hand-made” files for producing the dictionaries Same for Gaudi tools LHCb Core Software Meeting
LHCb Core Software Meeting, 18 Jan /5 The Tracking Example Track Event Classes Event/TrackEvent Tr/TrackFitEvent Kernel/LHCbKernel Tracking Tools Interfaces Tr/TrackInterfaces Tr/TrackMCInterfaces Kernel/LHCbKernel All dictionaries produced in each package Dictionaries produced In TrackPython package ALL TRACKING CLASSES AND TOOLS ARE AVAILABLE IN PYTHON Dictionaries produced In LHCbKernel package
LHCb Core Software Meeting, 18 Jan /5 Other Examples DaVinci tools Phys/PhysDict Any other package? Monte Carlo classes and tools Event/MCEvent … Where are other Python dictionaries built?
LHCb Core Software Meeting, 18 Jan /5 Proposal of Guideline Proposal We need a well-defined and consistent way of building dictionaries Dictionaries for custom classes and tools should be built in the same package where these are defined, not in separate packages Only exception: when a large number of related classes and interfaces are in separate packages, build a single dictionary in a dedicated new package - e.g. Det/DetSys - e.g. Det/DetSysBenefits Since non-MC/MC classes and tools are defined (or should) in separate packages, also the dictionaries will have the same clear separation - not quite the case at present, e.g. Phys/PhysDict - not quite the case at present, e.g. Phys/PhysDict When classes and tools are updated, corrected, etc. the corresponding dictionaries are automatically updated accordingly upon recompilation
LHCb Core Software Meeting, 18 Jan /5 What needs to be done (Event) Classes Dictionaries for all our LHCb event classes exist « by construction » Make sure we have dictionaries for all relevant custom classes that are not defined in XML Tool Interfaces Converge towards a small number of packages for interfaces Clearly separate Monte Carlo interfaces from real-data ones - e.g: Tr/Track(MC)Interfaces, Phys/Phys(MC)Interfaces, Det/DetSys, etc. Make sure we have dictionaries for all tool interfaces we may need/want to use in Python