Skip to content

MAINT: Remove the unused keepdim argument from np.ufunc.accumulate #8187

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

Merged
merged 1 commit into from
Jun 1, 2017

Conversation

eric-wieser
Copy link
Member

No description provided.

static char *kwlist2[] = {"array", "indices", "axis",
"dtype", "out", NULL};
static char *reduce_kwlist[] = {
"array", "axis", "dtype", "out", "keepdims", NULL};
Copy link
Member

@charris charris Oct 20, 2016

Choose a reason for hiding this comment

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

Umm, looks like you may have a hard tab in here. I preferred to previous format to tell the truth, although the alignment was a bit off on the second line.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's a set of spaces to align columns, to make visually diffing the arg lists easier.

The previous format was just indented with a bunch of soft tabs until it roughly aligned. I definitely think that having all the list items on one line is an improvement, but could be persuaded to remove that alignment

Copy link
Member

Choose a reason for hiding this comment

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

Big no-no. The way it was before was correct, and quite standard for C code, just off by a single space. See the doc/C_STYLE_GUIDE.rst.txt.

Copy link
Member

Choose a reason for hiding this comment

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

Oh, and no hard tabs.

Copy link
Member Author

Choose a reason for hiding this comment

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

There are no hard tabs here:

image

Copy link
Member Author

Choose a reason for hiding this comment

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

Reading that guide, the only mistake I seem to have made is indenting the wrapped line by one "tab" and not two. I don't see anything saying that if a line is wrapped, the first line should be made as long as possible. Which bit specifically are you calling a "no-no"?

Copy link
Member

Choose a reason for hiding this comment

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

Multiple spaces after the ,. It looks just awful.

Copy link
Member Author

@eric-wieser eric-wieser Oct 21, 2016

Choose a reason for hiding this comment

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

You'd argue that that the alignment of argument names isn't worth the extra spacing then? Happy to remove if so, although I think having it on one line is still desirable. I've added the second "tab" of indentation

Copy link
Member

Choose a reason for hiding this comment

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

Yes ;) I understand the temptation, but it is a false god. Along the same lines, PEP8 disapproves of aligning on equals signs, etc.

Copy link
Member

Choose a reason for hiding this comment

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

There might be some exceptions for tabular test data, where having data aligned in columns may be useful, but here is is just a distraction to (my) eye.

@@ -5919,6 +5919,13 @@ def luf(lamdaexpr, *args, **kwargs):
First array
B : array_like
Second array
dtype : data-type code, optional
The type used to represent the intermediate results. Defaults
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this is correct. I believe what happens is that the arrays are converted to the common type, or dtype if given, the operation done, and then converted to the out type if the out argument is given.

Copy link
Member

Choose a reason for hiding this comment

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

You can check that that is the case by using various combinations of dtype and out.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep, blindly copied from another ufunc method, without thinking hard enough about whether it applied

Copy link
Member Author

Choose a reason for hiding this comment

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

Totally missed the mark with this one - the arguments are just forwarded to the ufunc, including things like where which don't have all too sensible a result

@charris
Copy link
Member

charris commented Oct 20, 2016

Couple of style nits and probably the documentation is incorrect. The actual change looks OK.

@eric-wieser
Copy link
Member Author

Ok, should be good for another review

@eric-wieser eric-wieser force-pushed the accumulate-no-keepdim branch from 93fa698 to aedccb7 Compare October 22, 2016 00:25
@charris
Copy link
Member

charris commented Oct 22, 2016

OK, this looks good. However, current uses of np.ufunc.accumulate where the keepdims keyword is passed will error. The usual procedure is to issue a FutureWarning or DeprecationWarning warning for such cases and wait a couple of releases before making the change. I think FutureWarning is the way to go here. So I propose to mark this with a 1.14 milestone and ask you to submit another PR with the warning. Just check if the keepdims keyword has been set and issue a warning if so. I also think the documentation should be changed to show all the current keywords and the keepdims keyword documented as being dropped in a future release.

The temptation is to skip this process as it seems unlikely that the keyword is actually used by anyone, but it is best to follow procedure.

@charris
Copy link
Member

charris commented Oct 22, 2016

I apologize for not noticing the problem earlier, it just slipped my mind.

@eric-wieser
Copy link
Member Author

Ok, broken into three PRs:

@charris charris changed the title Remove the unused keepdim argument from np.ufunc.accumulate DEP: Remove the unused keepdim argument from np.ufunc.accumulate Oct 22, 2016
@charris charris added this to the 1.14.0 milestone Oct 22, 2016
@eric-wieser eric-wieser force-pushed the accumulate-no-keepdim branch from a77d0e0 to d15c75d Compare October 23, 2016 16:29
@eric-wieser
Copy link
Member Author

Ok, this one is all set for 1.14

@charris
Copy link
Member

charris commented Oct 23, 2016

OK, thanks.

@charris charris changed the title DEP: Remove the unused keepdim argument from np.ufunc.accumulate MAINT: Remove the unused keepdim argument from np.ufunc.accumulate Nov 4, 2016
@homu
Copy link
Contributor

homu commented Nov 23, 2016

☔ The latest upstream changes (presumably #8302) made this pull request unmergeable. Please resolve the merge conflicts.

@homu
Copy link
Contributor

homu commented May 6, 2017

☔ The latest upstream changes (presumably #9062) made this pull request unmergeable. Please resolve the merge conflicts.

@eric-wieser eric-wieser force-pushed the accumulate-no-keepdim branch from d4ea692 to f44ef18 Compare June 1, 2017 14:36
@eric-wieser
Copy link
Member Author

Rebased

@mhvk
Copy link
Contributor

mhvk commented Jun 1, 2017

This would seem OK to merge now, so I'll go ahead and do that. Nice to get the code cleaner, even if it is by a little bit at the time!

@mhvk mhvk merged commit f6822b4 into numpy:master Jun 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants