BUG: inspect.getmembers(Series) by topper-123 · Pull Request #38782 · 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
Conversation12 Commits9 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 }})
Make inspect.getmembers(Series)
work, previously raised an AbstractMethodError
.
xref: #38740
topper-123 changed the title
TST: test inspect.getmembers(Series) BUG: inspect.getmembers(Series)
@@ -302,7 +302,7 @@ ExtensionArray |
---|
Other |
^^^^^ |
- |
- ``inspect.getmembers(Series)`` no longer raises an ``AbstractMethodError`` (:issue:`38782`). |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note we backported the other issue. ok for this too.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove from here
pandas objects compatability with Numpy or Python functions
labels
original, such as DataFrame single columns slicing. |
---|
""" |
raise AbstractMethodError(self) |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't used on Series. Calling it on a Series should just result in an AttributeError.
@@ -302,7 +302,7 @@ ExtensionArray |
---|
Other |
^^^^^ |
- |
- ``inspect.getmembers(Series)`` no longer raises an ``AbstractMethodError`` (:issue:`38782`). |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove from here
Note there was quite some discussion about this on #31549 (it is also reported as a bug in python itself), and in the and this was fixed for _constructor_expanddim
differently in #33628
I don't care much about how it is folved, but probably good to be consistent for _constructor_expanddim
and _constructor_sliced
?
note we backported the other issue. ok for this too.
I would just leave it for 1.3 (it's not a regression like the other issue). You never know how some subclass might be using this method (or relying on the exact error class)
I would just leave it for 1.3 (it's not a regression like the other issue). You never know how some subclass might be using this method (or relying on the exact error class)
makes sense.
I don't care much about how it is folved, but probably good to be consistent for
_constructor_expanddim
and_constructor_sliced
?
I've made a new version, where they're the same: _constructor_sliced
is only for DataFrame
(it doesn't make sense for Series
) and _constructor_expanddim
is only available on Series
(doesn't make sense for DataFrame
, now that NDFrame higher than 2 is gone).
``_constructor_sliced`` ``NotImplementedError`` ``Series`` |
---|
``_constructor_expanddim`` ``DataFrame`` ``NotImplementedError`` |
=========================== ======================= ============= |
* ``DataFrame/Series._constructor``: Used when a manipulation result has the same (sub-)class as the original. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would keep the "same dimension as the original", because it doesn't necessarily need to return the same class (eg a subclass' _constructor
can return a non-subclassed DataFrame in certain cases)
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't like "same dimension as the original" because it could be understood like e.g. an array could be used, which would be wrong. By using "(sub-)class" is is implied that for e.g. for Series you have to supply a Series or a subclass of a Series (but not a DataFrame or a 1-dim array).
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this ok? My opinion is that it’s better to emphazise the type Here, rather than the dimensionality.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’ve changed this to say dimension rather than subclass. IDT the next gwo lines shares this issue, but let me know.
CyberQin pushed a commit to CyberQin/pandas that referenced this pull request
Labels
pandas objects compatability with Numpy or Python functions