API: EA._can_hold_na -> EDtype.can_hold_na
- [x] closes #40574
- [ ] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [x] whatsnew entry

> pandas/tests/extension/test_external_block.py:18: error: Cannot override final attribute "_can_hold_na" (previously declared in base class "Block")  [misc]

actually this is failing precommit pre-commit fixed I know this is an existing property on the ExtensionArray, but do we actually support (or want to support) an extension array that cannot hold missing values? (I don't think we currently have one, so this is also not really tested?) > I don't think we currently have one

Except for PandasArray, I assume (but since that's not actually stored in practice, that's a bit a special case anyhow) I think `Sparse[inty]`? i've added blocker since I don't think we should change this during the rc. so we either get it in for 1.3.0rc or move to 1.4/2.0 is the public/private question (and a rebase) the only outstanding issue?  im happy to make this private Also the question whether we should have this at all, IMO. And if we have that property, what does it mean? (what's the behaviour for operations like setitem or reindexing that can introduce missing values?) > Also the question whether we should have this at all, IMO. And if we have that property, what does it mean? (what's the behaviour for operations like setitem or reindexing that can introduce missing values?)

I'm open to having this discussion, but I think it can be done separately from the "where should this attribute live" discussion given that it already exists on EA. But if we are not yet sure if and how such property would be used, we can also leave it where it is for now? (or what problem is this PR fixing?)

If moving it, let's at least make it private and document it that way (as an internal property that no EA author should change, as that is undefined behaviour) > (or what problem is this PR fixing?)

The corner cases I want to rule out are where can_hold_na is values-dependent and potentially non-constant, e.g. (xref #40574)

```
class WeirdEA(ExtensionArray):
      @property
      def _can_hold_na(self) -> bool:
           return some_func(self[0])
``` this lgtm, i agree this should be on the dtype. @jorisvandenbossche ok here? Yeah, I won't object moving it. Just a tiny comment on the whatsnew. whatsnew removed + greenish Thanks @jbrockmendel 