Improve Python interface

[alecandido]

There are a bunch of items that can be improved in the Python interface, eventually leading to less code to maintain and better DX for pineappl_py consumers:

• drop Python layer, i.e. pineappl_py/pineappl, since at this point we have enough tools in PyO3 ecosystem (pyo3, rust-numpy, and extras, e.g. logging, if ever any of these will be needed) to provide a Python native experience without a dedicated layer (we can work with numpy arrays, add static/classmethods, and getters and setters with properties)
• code generation: a lot of bindings are really repetitive, and it is clear we can automate many of them; PyO3 itself is based on code generation, but mainly targeting Rust-powered Python libs, not bindings for standalone Rust libs, so we should clutter pineappl crate with PyO3 declarative macros; this is rather ugly, because then we might want to do the same for C bindings, and further ones in case we will ever support new languages (so scaling the number of macros with the languages supported); so either we find a native way to generate code using PyO3 macros, or we should write our own macros to generate the code corresponding to repeated patterns in current content of pineappl_py/src
• Python types: types are useful in Rust as in Python, so, if possible, let's propagate them to the second, even though PyO3 still indicates a manual approach
• better Python exceptions: we can use PyO3 support for plain exceptions, or its anyhow feature, since @cschwan already started introducing anyhow in main pineappl crate

[cschwan]

Here's another take on this: https://towardsdatascience.com/nine-rules-for-writing-python-extensions-in-rust-d35ea3a4ec29.

[alecandido]

Here's another take on this: towardsdatascience.com/nine-rules-for-writing-python-extensions-in-rust-d35ea3a4ec29.

I need some time to digest. If you already did (or you will do before), can you turn the content of the article in further points in the OP? (or a separate message if you like more)

[cschwan]

I was more a reminder for myself to read it 😃. I also saw it's an article from 2022, so I probably linked it before (I vaguely recall doing that).

[Radonirinaunimi]

With other burdens out of the way, I can now put this in the priority list. Will also need some time to digest everything above but will dive into the actual changes soon.

[alecandido]

This issue is pretty old, and PyO3 is quickly evolving. Please, check the newly available features before attempting any implementation :)

[cschwan]

One example that showcases how to simplify the implementation is commit 696ad6f, which uses some new features of PyO3 that allows to remove the corresponding Python wrapper method (done in commit 0d9876f).

[Radonirinaunimi]

Thanks both! I will have a look.

[cschwan]

I think this is pretty much done in #299, for everything else we should open a new Issue.