-
-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
DEV: stats: check for distribution/method keyword name collisions #13490
Conversation
The
|
@rgommers I guess I didn't ping you on this before. Since you suggested this originally, I thought you might be interested. Is this what you had in mind for the test? In the original suggestion, you mentioned changing the names and documenting the backwards incompatibility in the release notes - but would there be a deprecation message for a few versions? |
I have absolute no memory of that anymore. It looks like the |
Or maybe there a two of you : ) That would also explain how all the work gets done! In case you like to keep tabs on what other-you is saying, here's the post I meant. OK, maybe I'll chip away at this. Would be good to fix this sort of thing before we call something 2.0. |
Rebased on master, and here are the current failures.
|
Doc build issue looks unrelated to me.
I don't see anything else awry there. Let's see if it's happening in other PRs. |
Only a few issues have come up since September, all in
I'll take a look at them. Looks like it's because the public methods were overridden. I thought I sent an email to the mailing list in September, but I looked back and it was rejected because I sent it from the wrong address. I just resent. |
scipy/stats/_distn_infrastructure.py
Outdated
def moment(self, order=None, *args, **kwds): | ||
"""non-central moment of distribution of specified order. | ||
|
||
.. deprecated:: 1.8.0 |
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.
Looks like this will need to change to 1.9.0 everywhere, and 1.10.0 will need to be 1.11.0
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.
In recent deprecations we put 2.0. I am not sure if we decided yet if we are going to have 1.10 or go directly to 2.
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'm not sure what the plan is there. We could say "two releases" instead of assigning it a number.
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.
How about "deprecated in 1.9.0 and will be removed two releases after"
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.
Fine with me 👍
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.
Sounds good. I'll go ahead and update the version numbers tomorrow.
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.
Or today. Should be all set now after 547d1bb.
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.
@ev-br Wanted to make sure I understood - you suggested we "merge it for 1.9.x early in the release cycle." Does that mean we are waiting for something?
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.
Quite the reverse, the suggestion is to merge it once the deprecation wording is tweaked. And since it is now, I pressed the green button.
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.
Thanks @ev-br!
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.
Wow. This is epic. This can be made a poster example of "what you may need to do if you really care about backcompat".
A possible minor tweak could be to craft the wording of what is 1.9.0 + two releases, but I'd suggest we merge it as is, early in the 1.9.x release cycle and craft wording iteratively.
Thanks @mdhaber , great to see this loooong-standing bug fixed! |
Reference issue
gh-5982
What does this implement/fix?
There are name collisions between
scipy.stats
distribution shapes and method parameters. For example,alpha
is the name of a shape of thelevy_stable
distribution and it is used as a parameter of thestats.rv_continuous.interval
method, and this can cause problems when callinglevy_stable.interval
with keyword arguments.This PR adds a check for this condition.
Incidentally, it also finds distribution methods for which the parameters are not documented. This is the case for some of the overridden
fit
methods. For example:Additional information
I've not touched
refguide_check.py
or any other tools before, so I don't know what I'm doing.