-
Notifications
You must be signed in to change notification settings - Fork 87
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
fix: ak.num
should always return a useful (non-unknown length) type
#2785
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one fix, and then it's ready to merge (i.e. no need for a second review).
@jpivarski to confirm — forcibly returning |
I don't see anything wrong with that—internally in the codebase, we should be using In fact, if I had to make that distinction, I would expect the Awkward function to give me delayed data and the Python function to give me eager data, because Awkward knows about Dask and Python doesn't. I guess we're losing a case of "give me the eager, numerical length if you have it and a delayed token if you don't." But if I wanted that case, I wouldn't have guessed that |
Replaces #2774 by ensuring the return type of
ak.num
is always a valid "index type" (something that kernels produce).It might be that this is an integer rather than an
np.ndarray
(orcp.ndarray
, etc); this is up to the nplike. Right now, nplikes don't promote Python integers to 0D arrays.