API: ExtensionArray._concat_same_type doesn't define `axis`

[mroeschke]

Mentioned in #46008

The signature for ExtensionArray._concat_same_type is defined as def _concat_same_type(cls, sequence).

Some internal extension arrays define the method with an axis argument e.g. BaseMaskedArray._concat_same_type(cls, sequence, axis)

Some internal routines expect _concat_same_type to accept axis e.g _concat_datetime (hit by checking kind on the dtype).

I imagine either:

1. Internally, remove axis for internally defined _concat_same_type(cls, sequence, axis) (imagine not feasible)
2. Add axis to the ExtensionArray._concat_same_type signature.

[jbrockmendel]

Some internal routines expect _concat_same_type to accept axis e.g _concat_datetime (hit by checking kind on the dtype).

i expect this is a problem for pyarrow[datetime64]? i think the Technically Correct check would be dtype.kind in ["m", "M"] and not is_1d_only_ea_dtype(dtype)

[mroeschke]

i expect this is a problem for pyarrow[datetime64]?

Yeah I think testing with that dtype first uncovered this, but I imagine any custom EA who's EADtype is kind m/M would be impacted

[jbrockmendel]

Yeah I think testing with that dtype first uncovered this, but I imagine any custom EA who's EADtype is kind m/M would be impacted

This should now be fixed?

[mroeschke]

I think the original issue is fixed but shouldn't subclasses have the same _concat_same_type signature as the base method?

[jbrockmendel]

I think the original issue is fixed but shouldn't subclasses have the same _concat_same_type signature as the base method?

I think this is going to be an issue as long as some-but-not-all EAs support 2D. I guess we could add a mostly-irrelevant axis keyword to the base class but that would confuse 3rd party authors.