Closed alexpearce closed 3 years ago
Sounds good, but are you aware that root_numpy is considering using uproot as their backend? If they use it, I think it is better to just build on top of their implementation and not trying to implement the same thing at two different places.
Would there be any additional benefit in skipping root_numpy and directly invoking uproot (if root_numpy has the option to use uproot as their backend)
I wasn't aware. But absolutely, if root_numpy will already take care of the fallback behaviour then there's no need for root_pandas to implement it.
There doesn't seem to have been any change in root_numpy on this matter.
Indeed! But I think the functionality belongs more naturally in root_numpy, so scikit-hep/root_numpy#250 would be a better place to check the status.
I don't know if it makes sense to use uproot in root_pandas
and not directly start contributing to uproot.TTree.pandas
at this already implements much functionality of root_pandas.
e.g:
import uproot
f = uproot.open('file.root')
tree = f['tree']
df = tree.pandas.df()
@chrisburr, I won't close this task without your OK … but I would simply close it at this stage, and having in mind the developments in uproot
.
No need to write down here all reasons but this can safely be closed at this stage given all community discussions and developments in the last 3 years.
The uproot package is a Python implementation of some parts of ROOT's I/O capibilities. Interestingly for root_pandas, this includes TTree reading.
We should consider adding uproot as a 'backend' for loading TTrees from ROOT files, in addition to root_numpy. uproot doesn't handle writing at the moment, but I think that's OK.
We might also consider making uproot the default, installing it when installing root_pandas, and falling back to root_numpy when the user tries to write a file (and then complaining if ROOT isn't found).