Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

MAINT: Merge duplicate implementations of *vander2d and *vander3d functions #13079

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
Mar 11, 2019

Conversation

eric-wieser
Copy link
Member

@eric-wieser eric-wieser commented Mar 3, 2019

Every implementation is the same right now, other than calling a different *vander function.
Merging these into a single private function taking a callback results in significant deduplication.

Found by LGTM.


Split from #13078, since one commit needed further discussion, and I made some typos in the commit message anyway

… functions

Every implementation is the same right now, other than calling a different `*vander` function.
Merging these into a single private function taking a callback results in significant deduplication.

Found by LGTM.
@eric-wieser eric-wieser changed the title MAINT: Merge duplicate implementations of *vander2d and *vander3d functons MAINT: Merge duplicate implementations of *vander2d and *vander3d functions Mar 3, 2019
@eric-wieser eric-wieser requested a review from charris March 3, 2019 04:57
@charris
Copy link
Member

charris commented Mar 11, 2019

LGTM, might be interesting to see if the einsum bug mentioned in the polynomial.py versions got fixed.

Thanks Eric.

@charris charris merged commit 58640b7 into numpy:master Mar 11, 2019
@eric-wieser
Copy link
Member Author

Let's see if the LGTM nightly today spots that the duplicates are gone...

eric-wieser added a commit to eric-wieser/numpy that referenced this pull request Mar 12, 2019
@eric-wieser
Copy link
Member Author

@jhelie: Any idea why lgtm would show 0 alerts fixed on this PR, yet still reduce the total number of project alerts?

@jhelie
Copy link
Contributor

jhelie commented Mar 18, 2019

Hi Eric, I'm guessing the fixed alerts correspond to duplicate code flagged by rules such as this one. If so the automated code review does not show such non-attributable alerts, as documented here (point 3).

The idea is to only show results which can be fully accounted for by the PR analysed - which is not the case for statistical queries. But I too find it confusing and agree the current situation is not ideal, and we're thinking on how to improve the display of our results.

In the meantime you can check which queries have the non-attributable tag, see for instance here for the Python ones.

Hope that helps!

@eric-wieser
Copy link
Member Author

Thanks for the info. Kind of a shame that the fixes don't get attributed me, but I suppose they are only arbitrary internet points.

It would be nice if there were at least some way to be sure the alerts had been addressed, even if you don't want to attach an owner to them. Perhaps "N possibly unrelated alerts fixed" or something in the PR feedback.

@jhelie
Copy link
Contributor

jhelie commented Mar 25, 2019

Thanks for the feedback, I totally agree and we are discussing internally some ways to make this better.

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.

3 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.