This may not be a false positive. The EA interface does not specify (in the docstring) that a list is accepted for __getitem__, although maybe we have tests in the base extension tests that enforce this. will need to check.

Maybe the docs need to get updated, because this works:

>>> s=pd.array([1,2,3,4,5])
>>> s[[2,4]]
<IntegerArray>
[3, 5]
Length: 2, dtype: Int64

sure for our internal EAs. it's 3rd party EAs that may not support this.

So I guess there are two choices:

1. Require 3rd party EAs to support it and update the docs
2. Remove the List[Any] that I put in, and just mark the mypy error on that one place

I will assume you prefer (2), and will remove that

will look in detail tomorrow.

Last commits do it using (2).

Require 3rd party EAs to support it and update the docs

This one (not necessarily for this PR)

One other thought on this. There was some comment about having the EA's include a 2D signature, but I think that can be done in a subclass that implements it. So right now, the signature for __getitem__() is:

def __getitem__(
        self, item: Union[int, slice, np.ndarray]
    ) -> Union[ExtensionArray, Any]:

The discussion here is (to do in another PR) to make it (and change the docs):

def __getitem__(
        self, item: Union[int, slice, np.ndarray, List[int]]
    ) -> Union[ExtensionArray, Any]:

Note the use of List[int] here, not List[Any] as I had it before.

If there is a 2D EA that wants to allow Tuple[int, ...], it can have it's own signature that widens the EA signature:

def __getitem__(
        self, item: Union[int, slice, np.ndarray, List[int], Tuple[int, ...]]
    ) -> Union[ExtensionArray, Any]:

But we don't have to include that signature with Tuple[int,...] in the base EA class.

we've got ExtensionArray in the namespace, can make the isinstance check above for EA

I've changed the isinstance check, but you still need to declare result as ArrayLike, because the code below that line can return the result as an np.ndarray . Here's the excerpt (as now written):

        if isinstance(values, ExtensionArray):
            result: ArrayLike = values.unique()
            if self.dtype.kind in ["m", "M"] and isinstance(self, ABCSeries):
                # GH#31182 Series._values returns EA, unpack for backward-compat
                if getattr(self.dtype, "tz", None) is None:
                    result = np.asarray(result)

can't you just assert that this is a NpDtype here?

We decided to address astype() (where the above code is) in a later PR. That will remove the above.

see previous comment, remove the added type and this ignore will not be needed yet.

This shouldn't need to be changed. i've opened #41185 as a precursor to fix these false positives.

None seems redundant here.

when adding types, we should ensure that the types match the docstrings. From the PR title and previous discussion, IIUC astype was being done separately.

I would revert this for now until this method is sorted properly.

see also #41018 (comment) and response.

The docstring states we return np.ndarray and the one-liner suggests that too. We sometimes also return an ExtensionArray, this is dependent on the type of dtype.

my concern is that if we add the type now, this may get forgotten.

see previous comment, remove the added type and this ignore will not be needed yet.

I would leave these untyped for now.

These are passed through to numpy.argsort, so we should be able to be more precise.

try to avoid adding Any where we maybe able to more precise with further investigation.

side note: these actually don't seem to be passed in the base implementation.

same

see comments regarding using Sequence for ArrayLike