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

feat: made 'very optional' arguments keyword-only #1905

Merged
merged 6 commits into from
Nov 28, 2022

Conversation

jpivarski
Copy link
Member

@jpivarski jpivarski commented Nov 21, 2022

Also, the functions that are defined in terms of reducers (ak.ptp, ak.moment, ak.mean, ak.var, ak.std, ak.covar, ak.corr, ak.linear_fit, ak.softmax) now pass behavior consistently. (Previously, only ak.std made a half-hearted attempt.)

ak.to_categorical had a behavior argument added (somehow overlooked before).

The ak.*_like functions had their arguments reordered so that dtype is earlier than highlevel or behavior (which is the freedom to fix things that this PR is intended to make permanent).

In general, any ak.* function arguments that are "very optional"—configuring unusual situations—are now keyword-only, especially if they're booleans. It's very easy to mix up the order of boolean arguments. But axis arguments were left positional, since there are instances of positional axis in the wild.

The Content and Form subclasses, however, were left as they are. They're part of the low-level public API, and have only two arguments that are at all optional: parameters and nplike or form_key. These are all different types and unlikely to get misordered, and very unlikely to change order in the future. So there's not a strong need to make these arguments keyword-only.

The Type and Index subclasses are also low-level public API. Type's typestr argument and Index's metadata and nplike deserve to be keyword-only because they are rarely used and could be confusing. Any downstream developers who do use them should have a good understanding of what they are and do, at least at the level of spelling out their names.

That's everything that's going on in this PR!


📚 The documentation for this PR will be available at https://awkward-array.readthedocs.io/en/jpivarski-made-very-optional-arguments-keyword-only/ once Read the Docs has finished building 🔨

@jpivarski jpivarski linked an issue Nov 21, 2022 that may be closed by this pull request
@jpivarski jpivarski requested a review from ioanaif November 21, 2022 23:13
def mixin_class_method(ufunc, rhs=None, transpose=True):
def mixin_class_method(ufunc, rhs=None, *, transpose=True):
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is one that I should ask @nsmith- about: is it the case that rhs is likely to be positional but transpose should always be written out as keyword-only?

Copy link
Member

@nsmith- nsmith- Nov 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct. Any binary method would need the rhs specified but transpose is more rare.
As an aside, in retrospect, I should have made transpose default false but it is too late. That was the cause of scikit-hep/coffea#674

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, good to know about rhs.

About transpose: changing the default from True to False would be dangerous, even at the 2.0.0 boundary, unless we also change the name. As a keyword-only argument, the written-out old name would be different from the written-out new name, so old code can't pass through accidentally. After the 2.0.0 boundary, we'd have to have a period of time in which both names exist, with a warning on the old name, but we could make a clean switch to a new name if we do it before the 2.0.0 boundary.

What do you think? Is there a better word than transpose that would justify the change in default?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this will just have to stay. It is not a well-trodden path anyway.

Copy link
Collaborator

@ioanaif ioanaif left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@jpivarski
Copy link
Member Author

It's weird that build-docs failed with

/home/runner/work/awkward/awkward/docs/user-guide/how-to-convert-buffers.md:54: ERROR: Unknown interpreted text role "method".
/home/runner/work/awkward/awkward/docs/user-guide/how-to-create-arraybuilder.md:379: ERROR: Unknown interpreted text role "classY".

LGTM!

Okay, great! I'm looking at the build-docs error, and if I resolve that, then I'll merge this PR. My question to @nsmith- can be followed up in a new PR, if need be.

@jpivarski
Copy link
Member Author

There are more errors than that:

/home/runner/work/awkward/awkward/docs/reference/generated/ak.from_json.rst:24: ERROR: Unexpected indentation.
/home/runner/work/awkward/awkward/docs/reference/generated/ak.from_json.rst:143: ERROR: Unexpected indentation.
/home/runner/work/awkward/awkward/docs/reference/generated/ak.from_json.rst:185: ERROR: Unexpected indentation.
/home/runner/work/awkward/awkward/docs/reference/generated/ak.to_json.rst:13: ERROR: Unexpected indentation.
/home/runner/work/awkward/awkward/docs/reference/generated/ak.to_json.rst:25: ERROR: Unexpected indentation.
/home/runner/work/awkward/awkward/docs/user-guide/how-to-convert-buffers.md:54: ERROR: Unknown interpreted text role "method".
/home/runner/work/awkward/awkward/docs/user-guide/how-to-create-arraybuilder.md:379: ERROR: Unknown interpreted text role "classY".

The ones I've been able to trace back do seem to be legitimate errors, but I don't know why they'd stop the build now and not previously. I'll see what happens when I fix the ones I can fix.

@ioanaif
Copy link
Collaborator

ioanaif commented Nov 22, 2022

There are more errors than that:

/home/runner/work/awkward/awkward/docs/reference/generated/ak.from_json.rst:24: ERROR: Unexpected indentation.
/home/runner/work/awkward/awkward/docs/reference/generated/ak.from_json.rst:143: ERROR: Unexpected indentation.
/home/runner/work/awkward/awkward/docs/reference/generated/ak.from_json.rst:185: ERROR: Unexpected indentation.
/home/runner/work/awkward/awkward/docs/reference/generated/ak.to_json.rst:13: ERROR: Unexpected indentation.
/home/runner/work/awkward/awkward/docs/reference/generated/ak.to_json.rst:25: ERROR: Unexpected indentation.
/home/runner/work/awkward/awkward/docs/user-guide/how-to-convert-buffers.md:54: ERROR: Unknown interpreted text role "method".
/home/runner/work/awkward/awkward/docs/user-guide/how-to-create-arraybuilder.md:379: ERROR: Unknown interpreted text role "classY".

The ones I've been able to trace back do seem to be legitimate errors, but I don't know why they'd stop the build now and not previously. I'll see what happens when I fix the ones I can fix.

#1904 triggers the same errors, I haven't found the cause yet.

@jpivarski
Copy link
Member Author

The only one that I know how to fix is

ERROR: Unknown interpreted text role "classY".

It's pretty clear that this should be "class". I'll put that fix in, but it should still fail because of those other errors.

@codecov
Copy link

codecov bot commented Nov 22, 2022

Codecov Report

Merging #1905 (1ef77ed) into main (2dbaf51) will increase coverage by 0.00%.
The diff coverage is 97.40%.

❗ Current head 1ef77ed differs from pull request most recent head bcccb47. Consider uploading reports for the commit bcccb47 to get more accurate results

Additional details and impacted files
Impacted Files Coverage Δ
src/awkward/_util.py 82.46% <ø> (ø)
src/awkward/forms/bitmaskedform.py 86.07% <ø> (ø)
src/awkward/forms/bytemaskedform.py 86.30% <ø> (ø)
src/awkward/forms/emptyform.py 87.03% <ø> (ø)
src/awkward/forms/indexedoptionform.py 93.15% <ø> (ø)
src/awkward/forms/listform.py 82.71% <ø> (ø)
src/awkward/forms/listoffsetform.py 93.15% <ø> (ø)
src/awkward/forms/numpyform.py 97.08% <ø> (ø)
src/awkward/forms/recordform.py 88.57% <ø> (ø)
src/awkward/forms/regularform.py 85.52% <ø> (ø)
... and 95 more

@agoose77
Copy link
Collaborator

agoose77 commented Nov 22, 2022

The error here is actually due to LayoutBuilder failing in the LayoutBuilder notebook. I can take a quick look. This is actually something we should address; errors in notebooks aren't very visible in the tracebacks.

Aside - fixing the docs warnings is a long-term todo ...

@agoose77
Copy link
Collaborator

See #1907

@jpivarski
Copy link
Member Author

It's strange that #1904 now passes but #1905 still fails. Was 8d6abd6 wrong? It doesn't look like that's what the problem is.

@agoose77
Copy link
Collaborator

@jpivarski in the docs action log, I can see mention of a different notebook this time. I'll take a look.

@agoose77
Copy link
Collaborator

agoose77 commented Nov 22, 2022

@jpivarski looks like this was a "good" failure - apparently our test suite doesn't check ak.Array.mask! Eventually mypy will catch these kinds of bugs, but it will take time to get there.

@jpivarski
Copy link
Member Author

To avoid letting this get stale, I'm going to merge it now. (After a merge-with-main update and re-test.)

@jpivarski jpivarski enabled auto-merge (squash) November 28, 2022 15:26
@jpivarski jpivarski merged commit 88f7fef into main Nov 28, 2022
@jpivarski jpivarski deleted the jpivarski/made-very-optional-arguments-keyword-only branch November 28, 2022 15:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Some arguments should be keyword-only.
4 participants