Skip to content

API: EA._can_hold_na should be a dtype attribute, not EA #40574

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

Closed
jbrockmendel opened this issue Mar 22, 2021 · 0 comments · Fixed by #41654
Closed

API: EA._can_hold_na should be a dtype attribute, not EA #40574

jbrockmendel opened this issue Mar 22, 2021 · 0 comments · Fixed by #41654
Labels
API Design ExtensionArray Extending pandas with custom dtypes or arrays.
Milestone

Comments

@jbrockmendel
Copy link
Member

In practice in all the cases I'm aware of, _can_hold_na is always fixed at the EA subclass level, so we can immediately infer _can_hold_na from the dtype. But in principle ATM an EA subclass could do

class WeirdEA(ExtensionArray):
      @property
      def _can_hold_na(self) -> bool:
           return some_func(self[0])

We should make _can_hold_na an attribute of ExtensionDtype to pre-empt this.

@jbrockmendel jbrockmendel added Bug Needs Triage Issue that has not been reviewed by a pandas team member API - Consistency Internal Consistency of API/Behavior ExtensionArray Extending pandas with custom dtypes or arrays. API Design and removed API - Consistency Internal Consistency of API/Behavior Bug Needs Triage Issue that has not been reviewed by a pandas team member labels Mar 22, 2021
@jreback jreback added this to the 1.3 milestone May 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Design ExtensionArray Extending pandas with custom dtypes or arrays.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants