add python bindings for PIDHandler

[m-fila]

BEGINRELEASENOTES

• Added Python bindings for PIDHandler

ENDRELEASENOTES

Python test is selected tests from C++ version
Closes #396

[tmadlener]

Ah nice. I had mainly opened that issue as a reminder for myself not as a call to action ;)

What would be nice to check as well would be the constructors from frames, or from multiple collections via the static from methods. However, they clash with the from keyword from python. That was the main reason for me to not directly go to solve this ;) Would probably need some from_event and from_collections overloads on the c++ side to make things available on the python side in a working manner.

[tmadlener]

Adding the same creation functionality as is available in c++ in python via the from static functions seems not as straight forward as I had hoped. The problem is the python wrapper around the Frame that comes with podio. That makes overload resolution fail, and we would need to introduce a similar wrapper around PIDHandler here to deal with that, I think.

[m-fila]

There seems to be some problems with a lifetime when using pythonized std::optional and obtaining values from it 😐 For instance these seem to be not always the same

pid1 = handler.getPID(reco[0], 42)
pid1.value()

handler.getPID(reco[0], 42).value()

Possibly related to AIDASoft/podio#642

[m-fila]

I think a possible workaround for the problems with pythonized std::optional would be to add throwing interface and use it python bindings (and disable optional interface there)

[tmadlener]

If we are adding a dedicated python wrapper / interface here, that could also accommodate the necessary handling of the Frame wrapper.

[m-fila]

If we are adding a dedicated python wrapper / interface here, that could also accommodate the necessary handling of the Frame wrapper.

I'm not sure if I understand. The functions here are expecting to get a python wrapper for Frame and then get cppyy Frame object from it and use it with the functions expecting C++ Frame

Do you mean you'd like to have reimplementation of C++ functions in python using Frame wrapper methods without reaching to C++ Frame directly?

[tmadlener]

No, I was thinking that if we want the special handling of std::optional for the python PIDHandler, we need to write a python wrapper in any case. But now that I look at the diff again, I see that is already there(?) with the pythonizations doing all the necessary work of reaching through to the cppyy podio::Frame.

So now the actual question is: Can we make the std::optional work "as expected for python" with these pythonizations as well?

[m-fila]

I see. I tried hiding handling of std::optional inside the pythonizations hoping that if all the checking/unwrapping is done as soon as possible the lifetime issues might not kick-in. But I didn't manage to get it working reliably