BUG: fix IntegerArray astype with copy=True/False

[jorisvandenbossche]

xref #34307 (comment)

Right now, we were not copying the mask correctly with copy=True, and also not when the data was actually copied (then the mask also needs to be copied, even with copy=False)

[TomAugspurger]

LGTM. The matplotlib test failure is unrelated and I think reported elsewhere.

Does this need a whatsnew, or is it only on master?

[jorisvandenbossche]

One additional API question that pops up: in numpy, astype(.., copy=False) seems to return itself if it doesn't need to copy (I am actually also relying on this in the if data is self._data check).
But in the EA implementation, we always return a new array object, potentially with the same backing data. But we could in principle also do something like if dtype == self.dtype and not copy: return self (and that should already catch the one case where a copy can be avoided I think, and we could simply always copy in the other cases)

[jorisvandenbossche]

Does this need a whatsnew, or is it only on master?

Not only master it seems, will add a whatsnew.

[TomAugspurger]

I don't have a strong opinion on returning a new object backed by the data vs. just returning self.

[jreback]

lgtm very minor comment

[jreback]

should use AbstractMethodError

[jorisvandenbossche]

We actually use NotImplementedError in the base dtype class for this, so this is consistent with that (not fully sure why we do that though, there might be a reason)

[jreback]

kk yeah we should actually change that as this is a better error message (but ok)

[jorisvandenbossche]

Any preferences on what I do with copy=False? (returning a new object vs returning self)

[TomAugspurger]

Matching NumPy (returning the same object) seems OK.

[jorisvandenbossche]

Updated to return same object

[jreback]

lgtm, does this need a whatsnew? e.g. changed in 1.1?

[jorisvandenbossche]

Added a bug fix note

[jreback]

thanks @jorisvandenbossche