-
Notifications
You must be signed in to change notification settings - Fork 89
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
feat: made 'very optional' arguments keyword-only #1905
Conversation
def mixin_class_method(ufunc, rhs=None, transpose=True): | ||
def mixin_class_method(ufunc, rhs=None, *, transpose=True): |
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.
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?
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.
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
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.
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?
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.
I think this will just have to stay. It is not a well-trodden path anyway.
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.
LGTM!
It's weird that build-docs failed with
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. |
There are more errors than that:
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. |
The only one that I know how to fix is
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 Report
Additional details and impacted files
|
The error here is actually due to Aside - fixing the docs warnings is a long-term todo ... |
See #1907 |
@jpivarski in the |
@jpivarski looks like this was a "good" failure - apparently our test suite doesn't check |
To avoid letting this get stale, I'm going to merge it now. (After a merge-with-main update and re-test.) |
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, onlyak.std
made a half-hearted attempt.)ak.to_categorical
had abehavior
argument added (somehow overlooked before).The
ak.*_like
functions had their arguments reordered so thatdtype
is earlier thanhighlevel
orbehavior
(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. Butaxis
arguments were left positional, since there are instances of positionalaxis
in the wild.The
Content
andForm
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
andnplike
orform_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
andIndex
subclasses are also low-level public API.Type
'stypestr
argument andIndex
'smetadata
andnplike
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 🔨