Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

classname_of gives Exception when used on TBranch #542

Closed
jrueb opened this issue Jan 18, 2022 · 2 comments · Fixed by #1154
Closed

classname_of gives Exception when used on TBranch #542

jrueb opened this issue Jan 18, 2022 · 2 comments · Fixed by #1154
Assignees
Labels
feature New feature or request

Comments

@jrueb
Copy link
Contributor

jrueb commented Jan 18, 2022

Please consider the following source code

import uproot
import numpy as np


with uproot.recreate("test.root") as f:
    f["Tree"] = {"x": np.array([1,2,3,4,5])}

f = uproot.open("test.root")
print(f.classname_of("Tree/x"))

I would expect it to print "TBranch". However, it actually raises an exception: AttributeError: 'Model_TTree_v20' object has no attribute 'key'.

Uproot version: 4.1.9

@jrueb jrueb added the bug (unverified) The problem described would be a bug, but needs to be triaged label Jan 18, 2022
@jpivarski jpivarski added feature New feature or request and removed bug (unverified) The problem described would be a bug, but needs to be triaged labels Jan 18, 2022
@jpivarski
Copy link
Member

I hadn't thought of this as a potential use, but since "/" hides the distinction between paths into nested directories and paths into nested branches, it makes sense that one would try passing such a path into classname_of, streamer_of, class_of, title_of, etc.

The difficulty is that the path-handling is a specialized implementation in uproot.ReadOnlyDirectory.key

https://github.com/scikit-hep/uproot4/blob/3fe33aff6d6ed88203eed90f4edb5f2bc720f3e6/src/uproot/reading.py#L2006-L2021

which would have to get generalized out to be able to use them in the other functions that take paths.

Or maybe it just means that uproot.TBranch.HasBranches objects (i.e. TTree and all TBranch classes) should have a key method? (What about TBranches that contain TBranches? Would that work? I'm talking to myself...) Such a method can't return an uproot.reading.ReadOnlyKey because TTrees and TBranches don't have them the way that uproot.ReadOnlyDirectory does, but maybe a mocked "FakeKey" could duck-type to supply the appropriate information...

@jpivarski jpivarski added the next-release Required for the next release label Oct 31, 2022
@jpivarski jpivarski self-assigned this Nov 10, 2022
@jpivarski
Copy link
Member

This feature request is still open, but I'm not going to attempt to get it in before the 5.0.0 release (next Monday). I'm just removing that label.

@jpivarski jpivarski removed the next-release Required for the next release label Nov 28, 2022
@jpivarski jpivarski removed their assignment Nov 28, 2022
@ioanaif ioanaif self-assigned this Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
Status: Done!
Development

Successfully merging a pull request may close this issue.

3 participants