Skip to content

Conversation

@jorisvandenbossche
Copy link
Member

This follows-up on the comments here #62105 (comment) (on the PR that introduced _cast_pointwise_result / removed _from_scalars)

This PR does a few things:

  • Ensure (backwards) compability for external EAs, by ensuring that the default implementation for _cast_pointwise_result still does the minimal effort to try to return an instance of itself (the current implementation never returned the EA itself).
    • Doing this I also made it call _from_scalars for back compat with external EAs that already implemented this logic by overriding that method. This might only be geopandas, so also fine with eventually deprecating that method (and then _cast_pointwise_result can directly call _from_sequence, i.e. what the default impl for _from_scalars does now)
  • Add a small cast_pointwise_result functional wrapper around EA._cast_pointwise_result. The reason for this is that I don't think the EA should be responsible to know all kinds of (optional) type inference of pandas, it should just take care of the type inference to its own types.
    • External EAs could also achieve that by ensuring they always do result = super()._cast_pointwise_result(values), and we can document that they should do that (and then we can update the base class implementation whenever type inference defaults/options change). My feeling is that it is cleaner to not require that (i.e. let the EA handle just what it knows about, which is less error prone) and have that general logic outside of the EA, but I can also roll that back.
  • Expanded the docstring for _cast_pointwise_result for EA authors to clarify what this method should do (but this might need to be updated depending on the above)

cc @jbrockmendel

@jorisvandenbossche jorisvandenbossche added this to the 3.0 milestone Dec 15, 2025
@jorisvandenbossche jorisvandenbossche added the ExtensionArray Extending pandas with custom dtypes or arrays. label Dec 15, 2025
original_array: ArrayLike,
) -> ArrayLike:
"""
Try casting result of a pointwise operation back to the original dtype if
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is "original dtype" accurate here or would the "dtype family" phrasing be more accurate?

----------
result : array-like
Result to cast.
original_array : array-like
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't this an EA?

values = np.asarray(values, dtype=object)
return lib.maybe_convert_objects(values, convert_non_numeric=True)
try:
return type(self)._from_scalars(values, dtype=self.dtype)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC this change is bc older geopandas implements _from_scalars? can we catch+deprecate this so that we can eventually re-simplify this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, see my note about that in the top post (first bullet point)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I'm asking you to catch+deprecate

@jorisvandenbossche
Copy link
Member Author

jorisvandenbossche commented Dec 15, 2025

@jbrockmendel do you have a thought about the general idea of the cast_pointwise_result wrapper function vs the method having to call super() ? (or exposing maybe_convert_objects publicly so EAs can use that)
(the second bullet point in the top post)

@jbrockmendel
Copy link
Member

do you have a thought about the general idea of the cast_pointwise_result wrapper function vs the method having to call super() ? (or exposing maybe_convert_objects publicly so EAs can use that)
(the second bullet point in the top post)

Long term i think the extra layer of indirection is not great and I'd prefer the existing pattern. As an interim step for geopandas back-compat I'm fine with it. Instead of exposing maybe_convert_objects can't 3rd party EAs just do Series(valus).array?

@jorisvandenbossche
Copy link
Member Author

jorisvandenbossche commented Dec 15, 2025

As an interim step for geopandas back-compat I'm fine with it.

I didn't do that for back compat (updating the base array implementation of _cast_pointwise_result is sufficient for that, assuming that I move the call to maybe_convert_dtypes back into the method)

Long term i think the extra layer of indirection is not great and I'd prefer the existing pattern.

Personally I think the extra layer of indirection is the cleaner separate of concerns. An EA should not have to deal with general inference rules, just with the implementation of anything related to its own dtype (family).
Calling Series(values).array inside the base implementation of _cast_pointwise_result is also not great in terms of indirection, I would say (if that it what we recommend third-party EAs to do, that's what we should put in the base implementation, I think)

@jbrockmendel
Copy link
Member

Personally I think the extra layer of indirection is the cleaner separate of concerns. An EA should not have to deal with general inference rules, just with the implementation of anything related to its own dtype (family).
Calling Series(values).array inside the base implementation of _cast_pointwise_result is also not great in terms of indirection, I would say (if that it what we recommend third-party EAs to do, that's what we should put in the base implementation, I think)

I disagree on all counts, but don't care enough to argue about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ExtensionArray Extending pandas with custom dtypes or arrays.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants