-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
BUG: Matched SearchedSorted Signature with NumPy's #12413
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
Conversation
Where should I put tests for this compatibility issue? It would be great if I could just write one test for all of the classes that have a |
test_base will exercise this |
d22a921
to
6c70e12
Compare
Added test, and the test passes on Travis. Should be good to merge if there is nothing else. |
I need to get a new mouse. In any case, I did let the tests run with my new test, and Travis gave the green light. |
# See gh-12238 | ||
def testSearchSorted(self): | ||
mixin = IndexOpsMixin() | ||
mixin.values = np.array([1, 2, 3]) |
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.
no, see how we do for example .value_counts
where an object is constructed and looped thru. pls follow the same pattern
d3792d2
to
6cb665f
Compare
Tests are finally passing! Should be good to merge if there is nothing else. |
@@ -1117,3 +1117,4 @@ Bug Fixes | |||
- Bug in ``DataFrame.apply`` in which reduction was not being prevented for cases in which ``dtype`` was not a numpy dtype (:issue:`12244`) | |||
- Bug when initializing categorical series with a scalar value. (:issue:`12336`) | |||
- Bug when specifying a UTC ``DatetimeIndex`` by setting ``utc=True`` in ``.to_datetime`` (:issue:11934) | |||
- Bug in ``searchsorted`` argument signatures for ``IndexOpsMixin``, ``DatetimeIndex``, ``PeriodIndex``, and ```TimedeltaIndex`` that broke compatibility with ``searchsorted`` in ``numpy`` (:issue:`12238`) |
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.
you don't need to say all this, just say searchsorted
now accepts sorter
arg for compat with numpy.
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.
Done.
you can put in 0.18.0 |
a28afb0
to
62ca892
Compare
You accidentally cancelled all of my builds for this PR. |
oh sorry, push again :) |
62ca892
to
e147977
Compare
FYI: I believe you can restart a build, but no worries here since I just rebased onto |
@jreback : Also, regarding that |
887d4dc
to
f350442
Compare
@gfyoung ok then |
|
||
Parameters | ||
---------- | ||
v : array_like |
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 know this is annoying, but how about we rename v
-> value
. More readable args.
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 a previous comment we changed it to v
so that it matches the signature of numpy
, or maybe I misunderstood you then?
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.
no I think it was always like this. But we generally name things as value
in pandas (single character is too like q/kdb .... )
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.
Let's maybe just keep it at v
(as long as we do it better in our own methods!), you never know that someone used it as a keyword argument
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.
@jorisvandenbossche : v
is not used as a keyword in numpy
, and from a semantic point of view, I see no reason why it would be.
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.
Yikes, this is news to me. I guess I never encountered that before. Well, at least I know now and am slightly less of a Python noob because of that. Thanks for clarifying @kawochen!
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.
ok, just about to merge, then I saw you changed some of the v
-> value
. (you missed the datetimelikes).
So originally we had datetimelikes used key
(and I had you change it to v
). While Series
used v
.
So we have to break something.
Let's just keep the rename to value
(and fix the datetimelikes). Move the whatsnew note to API Changes
(and note that the argument name changed). I seriously doubt anyone is actually passing as a kw arg (the first arg).
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, so rename to value
and make a note in the API changes? Also, what do you mean by "datetimelikes"?
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.
datetimes, timedelta, period
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.
Got it. Done.
aa140f7
to
7e37570
Compare
|
5b33a6c
to
3a0de8b
Compare
@jreback : Changes have been made, and Travis approves. Should be good to merge then. |
Sorry, but I want to say it again. Changing a keyword's name is an API change that can break people's code, and since we want to change it because "we don't like the short name", it is certainly not an unavoidable API change, so IMO should not go into a minor release. |
@jorisvandenbossche : I find myself caught in a tug-of-war between you and @jreback on this issue, not to mention the push to land this is very high. It would be great if some consensus could be found on this. |
|
||
|
||
- ``searchsorted`` for ``Index`` and ``TimedeltaIndex`` now accept a ``sorter`` argument to maintain compatibility with numpy's ``searchsorted`` function (:issue:`12238`) | ||
- The parameter for specifying values to be inserted into a ``pandas`` object when calling its ``searchsorted`` method is now uniformly denoted as ``value`` |
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.
pls just make the whatsnew simpler. just say the signature changed the names of the arguments and put in a pointer to the signature.
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.
Done. I put [ci skip]
in my commit because this is only a doc change. So it should be good to merge if there is nothing else.
a30e10f
to
d7690c2
Compare
@jorisvandenbossche well, we already have that issue as |
But I think it is also not a big deal to just leave it for 0.19.0, just in case to be safe. But I agree the discrepancy with Index @gfyoung would you like to split the PR in two? one for the actual fix to searchsorted and one for the name change? |
ok, let's move the name change to 0.19.0. (you can just create an issue I think and I'll mark it). otherwise ok then. (back out |
d7690c2
to
1e6df5e
Compare
@jreback : Travis has finally given the green light on this one as well. Should be good to merge if there is nothing else to add. |
whoosh! thanks for the patience |
@jreback: No worries. Onto fixing the rest of |
Title is self-explanatory. Closes #12238.