Skip to content
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/CLN: Clean up to_dense signature deprecations #22910

Merged
merged 1 commit into from
Oct 18, 2018

Conversation

gfyoung
Copy link
Member

@gfyoung gfyoung commented Sep 30, 2018

Also deprecate fill in .get_values because its parameter was being passed to .to_dense, which
no longer accepts the fill parameter.

xref #14686.

@gfyoung gfyoung added Deprecate Functionality to remove in pandas Clean labels Sep 30, 2018
@gfyoung gfyoung added this to the 0.24.0 milestone Sep 30, 2018
@pep8speaks
Copy link

Hello @gfyoung! Thanks for submitting the PR.

@codecov
Copy link

codecov bot commented Sep 30, 2018

Codecov Report

Merging #22910 into master will decrease coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master   #22910      +/-   ##
==========================================
- Coverage   92.19%   92.18%   -0.01%     
==========================================
  Files         169      169              
  Lines       50954    50946       -8     
==========================================
- Hits        46975    46967       -8     
  Misses       3979     3979
Flag Coverage Δ
#multiple 90.61% <100%> (-0.01%) ⬇️
#single 42.28% <75%> (ø) ⬆️
Impacted Files Coverage Δ
pandas/core/arrays/sparse.py 92.52% <100%> (-0.03%) ⬇️
pandas/core/sparse/series.py 95.49% <100%> (-0.1%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1546c35...bfbae5c. Read the comment docs.

@jreback
Copy link
Contributor

jreback commented Oct 1, 2018

hmm, this might need to go in after @TomAugspurger refactor of Sparse (#22325)

@gfyoung
Copy link
Member Author

gfyoung commented Oct 1, 2018

Sounds good. I'll wait until that's done then.

@gfyoung
Copy link
Member Author

gfyoung commented Oct 16, 2018

Looks like Azure is failing on master but could be addressed by #23182.

@TomAugspurger
Copy link
Contributor

I'm fine with ignoring these failures for now if the code isn't touching window / pyarrow.

@gfyoung
Copy link
Member Author

gfyoung commented Oct 16, 2018

@TomAugspurger : These changes don't touch either of those. That being said, I'm in no rush to merge these, and I see that you are getting close on #23182.

Unless somebody needs these deprecations removed NOW, I think I can hold.

@jorisvandenbossche
Copy link
Member

I think we could deprecate get_values all together? (instead of only deprecating the keyword)

@gfyoung
Copy link
Member Author

gfyoung commented Oct 16, 2018

I think we could deprecate get_values all together? (instead of only deprecating the keyword)

@jorisvandenbossche :

Ah, hence the TODO in the original code. I think to_dense makes more sense semantically, so I don't see why we don't do that. If there aren't any objections, I can do that as well in this PR.

@jreback
Copy link
Contributor

jreback commented Oct 16, 2018

i agree we should deprecate get_values fully
but that means changing where it is used internally

i tried this a while back and it’s not so easy

maybe easier now that SpareArray is here

@jorisvandenbossche
Copy link
Member

"in principle" it should not be used internally (outside of sparse itself), as it is not part of the EA interface (or where it is used in sparse specific code, it should be replacable with to_dense)
but, don't know to what extent this "in principle" is true :)

I think it is certainly worth to check in this PR.

@gfyoung
Copy link
Member Author

gfyoung commented Oct 16, 2018

I didn't follow the sparse refactoring too closely, but to what extent are we trying to have a consistent interface for SparseArray with respect to SparseSeries and SparseDataFrame ?

I ask this because although I'm also inclined to deprecate get_values, it is of course a completely valid method for the latter two. The devil's advocate in me thinks then that the interface for sparse object methods becomes a little inconsistent if you have to use to_dense for one class but are allowed to use get_values for the others.

@jreback
Copy link
Contributor

jreback commented Oct 17, 2018

this looks fine. can you rebase to get this passing. ping on green.

@jreback
Copy link
Contributor

jreback commented Oct 17, 2018

I think we have an issue about deprecating .get_values() generally, which as I said above we should do (but slightly tricky).

@gfyoung
Copy link
Member Author

gfyoung commented Oct 17, 2018

this looks fine. can you rebase to get this passing. ping on green.

@jreback : I'm waiting on #23182 to be merged.

@jreback
Copy link
Contributor

jreback commented Oct 17, 2018

@gfyoung yep ok.

@jorisvandenbossche
Copy link
Member

jorisvandenbossche commented Oct 17, 2018

to what extent are we trying to have a consistent interface for SparseArray with respect to SparseSeries and SparseDataFrame ?

There does not need to be a consistency here, since we are considering deprecating SparseSeries/DataFrame alltogether.

I still think it doesn't make sense to only deprecate the keyword if we are actually planning to deprecate the full method. I would directly do that, otherwise you annoy users twice for nothing.

@TomAugspurger
Copy link
Contributor

TomAugspurger commented Oct 17, 2018 via email

@gfyoung
Copy link
Member Author

gfyoung commented Oct 17, 2018

As @jreback had warned beforehand, there are unfortunately still some issues with trying to deprecate to_dense at the moment. I would prefer to attempt to do this in a fresh PR once this is merged.

@jorisvandenbossche
Copy link
Member

jorisvandenbossche commented Oct 17, 2018

I think it was about get_values and not is_dense (maybe a typo)?

But, can you give a bit more details about the issues you encountered? That's useful information to keep track of.

@gfyoung
Copy link
Member Author

gfyoung commented Oct 17, 2018

@jorisvandenbossche : There were some errors in the sparse index testing. I'll try to debug as a follow-up.

@gfyoung
Copy link
Member Author

gfyoung commented Oct 18, 2018

@jreback : Addressed all comments, and all is green again! PTAL.

@jorisvandenbossche
Copy link
Member

@gfyoung was looking at the diff now, and was wondering: can't you simply remove the fill keyword in get_values as well instead of deprecating it? Because you already got a deprecation warning before, since this was simply passed to to_dense, which raised the future warning.

@gfyoung
Copy link
Member Author

gfyoung commented Oct 18, 2018

@jorisvandenbossche : Ah! That's a good point! Let me do that then (given the warning message was not specific to either method).

Also deprecate `fill` in `.get_values` because its
parameter was being passed to `.to_dense`, which
no longer accepts the `fill` parameter.

xref pandas-devgh-14686.
@gfyoung gfyoung force-pushed the to-dense-depr-remove branch 2 times, most recently from 624568a to bfbae5c Compare October 18, 2018 10:09
@gfyoung
Copy link
Member Author

gfyoung commented Oct 18, 2018

@jreback @jorisvandenbossche : Comments addressed, and all is green! PTAL.

@jreback jreback merged commit 8963218 into pandas-dev:master Oct 18, 2018
@jreback
Copy link
Contributor

jreback commented Oct 18, 2018

thanks @gfyoung

@gfyoung gfyoung deleted the to-dense-depr-remove branch October 18, 2018 18:53
tm9k1 pushed a commit to tm9k1/pandas that referenced this pull request Nov 19, 2018
Also deprecate `fill` in `.get_values` because its
parameter was being passed to `.to_dense`, which
no longer accepts the `fill` parameter.

xref pandas-devgh-14686.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Clean Deprecate Functionality to remove in pandas
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants