Closed masonproffitt closed 3 years ago
Should it just assume the highest one? Or do so with a default option?
I would think it should do whatever uproot.open('file.root').key('Events')
does if there are multiple cycle numbers present for Events
, which seems to be taking the highest one:
>>> uproot.open('root://eospublic.cern.ch//eos/opendata/cms/derived-data/AOD2NanoAODOutreachTool/Run2012BC_DoubleMuParked_Muons.root').key('Events')
<ReadOnlyKey Events;75: TTree (seek pos 2244422054) at 0x7f6d397692e0>
The actual selection of TTree follows the same code path in lazy and non-lazy cases; what's different is the preparation of key names to ask for. So the substantial part of PR #500 (!) is
@@ -2965,7 +2965,7 @@ def _regularize_object_path(
**options # NOTE: a comma after **options breaks Python 2
).root_directory
if object_path is None:
- trees = [k for k, v in file.classnames().items() if v == "TTree"]
+ trees = file.keys(filter_classname="TTree", cycle=False)
if len(trees) == 0:
if allow_missing:
return None
I also had to fix ReadOnlyFile.keys
(and values
, items
, classnames
) to not return duplicates when the disambiguating cycle
number is suppressed. Actually, that part could be considered a bug, but no one ever brought it up before. (Mapping.keys
should return unique strings...)
Functions like
uproot.lazy
normally work without specifying the tree name if there is only one TTree in the file, but this doesn't work if there are multiple cycle numbers:This is confusing since you otherwise never have to worry about cycle numbers. For example:
uproot.open('root://eospublic.cern.ch//eos/opendata/cms/derived-data/AOD2NanoAODOutreachTool/Run2012BC_DoubleMuParked_Muons.root:Events')
doesn't require a cycle number.