-
-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
DEPR: deprecate default of skipna=False in infer_dtype #24050
Conversation
Hello @h-vetinari! Thanks for updating the PR. Cheers ! There are no PEP8 issues in this Pull Request. 🍻 Comment last updated on January 04, 2019 at 11:14 Hours UTC |
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.
Some comments on specific changes
Codecov Report
@@ Coverage Diff @@
## master #24050 +/- ##
==========================================
- Coverage 42.45% 42.44% -0.01%
==========================================
Files 161 161
Lines 51561 51561
==========================================
- Hits 21888 21886 -2
- Misses 29673 29675 +2
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #24050 +/- ##
==========================================
+ Coverage 92.38% 92.38% +<.01%
==========================================
Files 166 166
Lines 52490 52490
==========================================
+ Hits 48493 48494 +1
+ Misses 3997 3996 -1
Continue to review full report at Codecov.
|
Hmm...you do have to try a little just to get to the function via Python, so I'm leaning towards ok, but not 100% certain though. cc @jreback |
I don't think this was ever deprecated. So not really possible to actually switch it now. If you want to add a deprecation warning if its not passed (e.g. make the default |
@jreback Also, it's a method in a module that's explicitly marked as private (big red box at https://pandas.pydata.org/pandas-docs/stable/api.html), so I wonder if deprecation is necessary at all? |
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.
@bashtage
Thanks for taking a look!
What happens when you have
IIRC None is an N/A type. |
This also doesn't change between the two variants:
That said, the result is a bit unexpected, and seems to be due the 2d case being handled differently. In any case, both variants (what you commented on, resp. what I'm changing it to) coincide also for 1d here:
|
I implemented the DeprecationWarning like you requested - this should be ready. |
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 for the review
@jreback Merged and green. |
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
I think there's a misunderstanding here. Please have a look at my response and TAL.
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
I have very limited capability over the holidays. Will most likely not be able to make a precursor before the cutoff. I could switch everything to skipna=False
, and then things would definitely be the same as before.
@jreback |
Merged in #24560 and restored the state that was approved by @TomAugspurger (in 1ea21fe), which is all green now. The philosophy of that was to use To avoid getting bogged down in discussing the implications before the cut-off, I've added the last commit, which maintains the current behaviour ( If changing the defaults in the codebase is desired, I can make a follow-up with 1ea21fe. |
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 lgtm. very minor change. ping on green.
assert result == 'integer' | ||
|
||
def test_warn(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.
rename to test_deprecation & add the issue number as a comment
@jreback |
thanks @h-vetinari I think we should only change to True in non-trivial cases, IOW the trivial ones can stay False; I think should be very explicit and deliberate for True. (so a lot of the string like ones this makes sense) |
A bit late to the party here :-), but:
I went quickly through the PR here but didn't directly find any reasoning apart from "Would make life easier in a couple of places (especially in cleaning up some of the casting code)." in the top post. Was this discussed in another issue? Also to quote Jeff from his last comment just above: "IOW the trivial ones can stay False; I think should be very explicit and deliberate for True." (my emphasis) For the string case I think it certainly makes sense to have this as default, but for the integer case you now get a inconsistency between what
|
Actually, my main reason for deprecating was that it has been "announced" in the docstring since 0.21 (see diff of this PR):
That being said, I think the inference generally makes more sense when nans are ignored (just that historically,
I agree that it's not very user-facing. I have no strong preference for the type of warning. |
git diff upstream/master -u -- "*.py" | flake8 --diff
I know that
v.0.22
is generally not counted towards the "3 major releases between warning and deprecation" policy, but since this is a private method, I'm thinking it should be OK?Would make life easier in a couple of places (especially in cleaning up some of the casting code).