-
-
Notifications
You must be signed in to change notification settings - Fork 18.3k
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
Standardize function signatures #14645
Standardize function signatures #14645
Conversation
e529572
to
6c59f44
Compare
Current coverage is 85.22% (diff: 97.67%)@@ master #14645 diff @@
==========================================
Files 143 143
Lines 50807 50813 +6
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
+ Hits 43297 43304 +7
+ Misses 7510 7509 -1
Partials 0 0
|
@@ -1818,3 +1818,31 @@ def test_op_duplicate_index(self): | |||
result = s1 + s2 | |||
expected = pd.Series([11, 12, np.nan], index=[1, 1, 2]) | |||
assert_series_equal(result, expected) | |||
|
|||
def test_searchsorted(self): |
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.
put these tests alongside the other ones / u need to search for them
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.
Alongside what other ones? Where should I put these tests?
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.
u need to search for them
i think that's pretty clear
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.
Fair enough, though as written, the "/" made the sentence confusing.
@@ -53,6 +53,9 @@ Other API Changes | |||
Deprecations | |||
^^^^^^^^^^^^ | |||
|
|||
- ``Series.repeat()`` has deprecated the ``reps`` parameter in favor of ``repeats`` (:issue:`12662`) | |||
- ``Index.repeat()`` and ``MultiIndex.repeat()`` have deprecated the ``n`` parameter in favor of ``repeats`` (:issue:`12662`) | |||
- ``Categorical.searchsorted()`` and ``Series.searchsorted()`` have deprecated the ``v`` parameter in favor of ``key`` (:issue:`12662`) |
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.
Doesn't numpy
still call this parameter v
?
In [9]: a = np.array([1,2,3])
In [11]: a.searchsorted?
Docstring:
a.searchsorted(v, side='left', sorter=None)
Find indices where elements of v should be inserted in a to maintain order.
For full documentation, see `numpy.searchsorted`
See Also
--------
numpy.searchsorted : equivalent function
Type: builtin_function_or_method
In [12]: np.__version__
Out[12]: '1.11.1'
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.
Oh, I see that Index
was already using key
as the name - I guess I don't feel strongly between the two.
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 don't see a reason to follow the numpy
convention, especially since it is very unclear what exactly that parameter is. Unless someone strongly objects, I would prefer to use key
.
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.
so we typically will use value
in this case (not sure why it was key
in the timedelta one). We are searching the .values
of the object, and NOT the index (where we typically use key
).
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.
@jreback : Okay...so should we still keep to key
or should they all be changed to value
for searchsorted
?
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.
Since we are already changing keyword names, for me it is OK to choose value
instead of key
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, fair enough. Will change.
6c59f44
to
fdd6fbf
Compare
fdd6fbf
to
a29bba6
Compare
lgtm. |
c4e0bb8
to
26f7be9
Compare
26f7be9
to
c5059b6
Compare
tm.assert_index_equal(result, expected) | ||
|
||
with tm.assert_produces_warning(FutureWarning, | ||
check_stacklevel=False): |
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.
Is the check_stacklevel=False
needed here? This looks like a simple example where stacklevel=2 should just work
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.
Yes, it is needed unfortunately.
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.
For which builds does it error? If we always have to pass check_stacklevel=False
, even for those (I think) straightforward case, there is not much point in having the keyword.
For me it passes locally.
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.
It didn't pass locally for me. TBH, not really sure why we need this argument in the first place.
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.
Can you show the error traceback?
The reason we have this argument, is to ensure that the FutureWarnings are correctly attributed. Towards users, this is really helpful.
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.
See #9584
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.
Perhaps, but look at how many times we have had to pass in check_stacklevel=False
. I don't necessarily object to specifying a stack level, but if we're unable to consistently specify the correct stack level, why are we using it in our tests?
BTW, I'm not trying to avoid showing my error traceback. I'm just in the middle of another PR.
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.
Ran the tests again to see if I could replicate the issue but invoked the tests in a different way, and I could not replicate. So let's see what Travis says about it.
3d469de
to
3cdded5
Compare
@jreback , @jorisvandenbossche : Everything seems to be passing still. Ready to merge if there are no other concerns. |
- ``Series.repeat()`` has deprecated the ``reps`` parameter in favor of ``repeats`` (:issue:`12662`) | ||
- ``Index.repeat()`` and ``MultiIndex.repeat()`` have deprecated the ``n`` parameter in favor of ``repeats`` (:issue:`12662`) | ||
- ``Categorical.searchsorted()`` and ``Series.searchsorted()`` have deprecated the ``v`` parameter in favor of ``value`` (:issue:`12662`) | ||
- ``IndexOpsMixin.searchsorted()``, ``TimedeltaIndex.searchsorted()``, ``DatetimeIndex.searchsorted()``, and ``PeriodIndex.searchsorted()`` have deprecated the ``key`` parameter in favor of ``value`` (:issue:`12662`) |
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.
Listing IndexOpsMixin
is not needed here I think
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.
Fair enough. Done.
@@ -97,6 +97,10 @@ def test_repeat(self): | |||
numbers, names.repeat(reps)], names=names) | |||
tm.assert_index_equal(m.repeat(reps), expected) | |||
|
|||
with tm.assert_produces_warning(FutureWarning, | |||
check_stacklevel=False): |
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 you can removed all other occurences of check_stacklevel=False
in this PR as well
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.
Seems so. Done.
Standardize the following function signatures: 1) repeat(reps, *args, **kwargs) 2) searchsorted(value, side='left', sorter=None) Closes pandas-devgh-12662.
3cdded5
to
f448639
Compare
@jreback , @jorisvandenbossche : Changes made, and everything seems to be passing still. Ready to merge if there are no other concerns. |
For Index and MultiIndex. xref pandas-devgh-14645.
For Index and MultiIndex. xref pandas-devgh-14645.
For Index and MultiIndex. xref gh-14645.
The parameter is "value" across the board. xref pandas-devgh-14645.
The parameter is "value" across the board. xref pandas-devgh-14645.
The parameter is "value" across the board. xref pandas-devgh-14645.
"values" is the law of the land. xref pandas-devgh-14645.
"values" is the law of the land. xref pandas-devgh-14645. Follow-up to pandas-devgh-15601.
"values" is the law of the land. This usage is internal, hence why we aren't going through a deprecation cycle. xref pandas-devgh-14645. Follow-up to pandas-devgh-15601.
"values" is the law of the land. This usage is internal, hence why we aren't going through a deprecation cycle. xref pandas-devgh-14645. Follow-up to pandas-devgh-15601.
The parameter is "value" across the board. xref gh-14645.
"values" is the law of the land. This usage is internal, hence why we aren't going through a deprecation cycle. xref pandas-devgh-14645. Follow-up to pandas-devgh-15601.
"values" is the law of the land. xref pandas-devgh-14645. Follow-up to pandas-devgh-15601.
For Index and MultiIndex. xref pandas-devgh-14645.
The parameter is "value" across the board. xref pandas-devgh-14645.
"value" is the law of the land. xref pandas-devgh-14645. Follow-up to pandas-devgh-15601.
For Index and MultiIndex. xref pandas-devgh-14645.
The parameter is "value" across the board. xref pandas-devgh-14645.
"value" is the law of the land. xref pandas-devgh-14645. Follow-up to pandas-devgh-15601.
Standardize the following function signatures:
repeat(reps, *args, **kwargs)
searchsorted(value, side='left', sorter=None)
Closes #12662.