Problem reading TTree because of attribute error

[casesyh]

I was trying to read a tree from a root file, I got the error below. However reading other trees in the same root file was fine. Thanks.

AttributeError Traceback (most recent call last)

in 1 path_root_file = '~/TracksAndEvents.root' 2 f = uproot.open(path_root_file) ----> 3 f['discPoints1D'].keys() /usr/local/lib/python3.7/site-packages/uproot/rootio.py in __getitem__(self, name) 223 224 def __getitem__(self, name): --> 225 return self.get(name) 226 227 def __len__(self): /usr/local/lib/python3.7/site-packages/uproot/rootio.py in get(self, name, cycle) 357 358 if last is not None: --> 359 return last.get() 360 elif cycle is None: 361 raise _KeyError("not found: {0}\n in file: {1}".format(repr(name), self._context.sourcepath)) /usr/local/lib/python3.7/site-packages/uproot/rootio.py in get(self, dismiss) 1008 1009 try: -> 1010 return _classof(self._context, self._fClassName).read(self._source, self._cursor.copied(), self._context, self) 1011 finally: 1012 if dismiss: /usr/local/lib/python3.7/site-packages/uproot/rootio.py in read(cls, source, cursor, context, parent) 948 out = cls.__new__(cls) 949 out = cls._readinto(out, source, cursor, context, parent) --> 950 out._postprocess(source, cursor, context, parent) 951 return out 952 /usr/local/lib/python3.7/site-packages/uproot/tree.py in _postprocess(self, source, cursor, context, parent) 293 for branch in self.itervalues(recursive=True): 294 if len(branch._fLeaves) > 0: --> 295 branch._countleaf = branch._fLeaves[0]._fLeafCount 296 if branch._countleaf is not None: 297 branch._countbranch = leaf2branch.get(id(branch._countleaf), None) AttributeError: 'Undefined' object has no attribute '_fLeafCount'

[jpivarski]

It was unable to read one of the TBranches and created an object of type Undefined as a placeholder, then the Undefined object doesn't have some of the data it needs. Even though the TTrees are in the same file, they might have different versions if they got into that file by copying them from other files in some strange way. (Otherwise, they'd all have the same version.)

Could you try this in Uproot 4? It might work there because Uproot 4 has better deserialization routines (better able to deal with different versions of the same class), but even if it doesn't, Uproot 4 has better debugging output that could help to figure out what's happening in this file.

[casesyh]

Thanks. Uproot 4 works. When would uproot 4 be the official uproot?

[jpivarski]

I'm glad it works for you! (So I'll be closing this issue.)

Uproot 4 being "official" can mean several different things:

• When the package named uproot in PyPI points to the Uproot4 code with PyPI version number 4.0+ and the GitHub repos are moved such that scikit-hep/uproot → scikit-hep/uproot3 and scikit-hep/uproot4 → scikit-hep/uproot: this will happen before the end of the year. (That's a deadline.) The exact date depends on when I finish the last two features: file-writing and documentation.
• When Uproot 4 gets the full polish and documentation that Awkward1 has: clearly before the above. If I prioritize it over file-writing, it could be done in a month.
• When Uproot 4 is usable for analysis—that is, I believe it is a better codebase than Uproot 3: now. The only reason I'm not making more noise about Uproot 4 being "done" in this sense is because users really need documentation: pointing them to a repo without at least a cheat sheet of how to move from Uproot 3 to 4 wouldn't be fair.

But that's also why it has a different Python package name, so that you can make a gradual transition, taking the best of both until Uproot 4 completely replaces it in PyPI.

(And since the current uproot will be moving to uproot3, it will forever be available as import uproot3 as uproot for projects that depend on the old interface.)