COMPAT: Expand compatibility with fromnumeric.py by gfyoung · Pull Request #12810 · 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
Conversation251 Commits1 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 }})
Fixes up OR addresses what are AFAICT almost if not all of the incompatibilities pandas currently has with numpy.core.fromnumeric. My goodness, were there a lot of them.
Closes #12638.
Closes #12644.
Closes #12687.
This was referenced
Apr 6, 2016
pandas objects compatability with Numpy or Python functions
label
| @@ -105,6 +104,56 @@ API changes |
|---|
| - ``pd.show_versions()`` now includes ``pandas_datareader`` version (:issue:`12740`) |
| - Provide a proper ``__name__`` and ``__qualname__`` attributes for generic functions (:issue:`12021`) |
| .. _whatsnew_0181.numpy_compatibility |
| Compatibility between pandas array-like methods (e.g. ```sum`` and ``take``) and their analogous |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
say numpy counterparts, rather than analagous
dont need (generally with *args, and **kwargs).
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
| Do not call this function via the numpy library, as numpy's version |
|---|
| has a completely different purpose (returns number of dimensions in |
| an array)! |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jreback : How about this warning? Should it be kept, or should it be the user's responsibility to know the two 'rank' functions serve completely different purposes?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we have a really different signature as pandas rank is much more friendly to different dtypes, you can prob just raise on this one if someone does np.rank(...) but if you can't it doesn't really matter. again if someone is doing it, then they must know what they are doing, no amount of documentation will help.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough. I think I'll just remove it then. In worst case, if a user tries to call via the numpy library we can say that, "look, the documentation is different".
I hate to be a curmudgeon on this issue, but how do we benefit from increasing our API coupling to NumPy? We've been discussing moving precisely in the opposite direction.
I've made all of the necessary changes (for ones I didn't make I provided reason(s) for not doing so), and Travis is still passing. Codecov is doing something strange as it is with my test_parsers PR.
| data[5] = np.nan |
| out = np.cumsum(SparseArray(data, fill_value=2)) |
| self.assertNotIsInstance(out, SparseArray) |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same reference here
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same response as above
@gfyoung ok just a couple minor comments. pls rebase and lmk when green. also your numpy side-pr won't cause any issues (as it will be merged to numpy after this)?
ok, I think this looks good. give a nice update / rebase and force push. ping when green.
Augment pandas array-like methods with appropriate parameters (generally, '*args' and '**kwargs') so that they can be called via analogous functions in the numpy library they are defined in 'fromnumeric.py'.
Closes pandas-devgh-12638. Closes pandas-devgh-12644. Closes pandas-devgh-12687.
@jreback : Travis is giving the green light. Ready to merge if there is nothing else.
jreback pushed a commit that referenced this pull request
Follow-on to #12810 by expanding compatibility with fromnumeric.py in the following modules:
- tslib.pyx
- window.py
- groupby.py and resample.py (shared classes)
Closes #12811.
Author: gfyoung gfyoung17@gmail.com
Closes #13148 from gfyoung/fromnumeric-compat-continued and squashes the following commits:
eb4762c [gfyoung] COMPAT: Expand compatibility with fromnumeric.py
Please pull this solution to main library of pandas because still this problem is not solved...
@hemangjoshi37a this changeset is already included in the main pandas library since the 0.18.1 release. If you still have a problem related to this, please open a new issue with a reproducible example.
Labels
pandas objects compatability with Numpy or Python functions