DEPR: deprecate (Sparse)Series.from_array by jorisvandenbossche · Pull Request #18258 · pandas-dev/pandas (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation9 Commits5 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Closes #18213.
It's a bit annoying that I have to keep it as internal method. On the other hand this might signal that from_array actually has some use case ..
| fastpath=fastpath) |
|---|
| @classmethod |
| def _from_array(cls, arr, index=None, name=None, dtype=None, copy=False, |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
its prob easier just to elminate this and deal with SparseSeries directly in the Series constructor. Do we have an issue for this?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
annoyingly we'd actually have to do this in __new__ (but not that big of a deal)
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that would be cleaner. But it is also an API change that Series(..) would no longer always return a Series but depending on the input also SparseSeries.
So the question is if we actually want this. I can open an issue about it though.
@jorisvandenbossche @jreback : This commit introduced the first (and only) instance of pytest.warns instead of our in-house tm.assert_produces_warning. Do we have a preference for which should be used now that we require pytest >= 3.1 ?
@gfyoung let's just use assert_produces_warning. and alway pls add a lint rule to fail onpytest.warns. We could of course change to use pytest.warns (maybe) but that's a different issue.
@jreback : I figured as such. Thanks for confirming.
gfyoung added a commit to forking-repos/pandas that referenced this pull request
Per discussion in pandas-devgh-18258, we are prohibiting its use in tests, at least for the time being.
gfyoung added a commit to forking-repos/pandas that referenced this pull request
Per discussion in pandas-devgh-18258, we are prohibiting its use in tests, at least for the time being.
jreback pushed a commit that referenced this pull request
- MAINT: Check for pytest.warns in tests
Per discussion in gh-18258, we are prohibiting its use in tests, at least for the time being.
- MAINT: Patch lint error with pytest.warns
The lint correctly fails on this line.