id,node_id,number,title,user,state,locked,assignee,milestone,comments,created_at,updated_at,closed_at,author_association,active_lock_reason,draft,pull_request,body,reactions,performed_via_github_app,state_reason,repo,type
2125478394,PR_kwDOAMm_X85mZIzr,8723,(feat): Support for `pandas` `ExtensionArray`,43999641,closed,0,,,23,2024-02-08T15:38:18Z,2024-04-18T12:52:06Z,2024-04-18T12:52:03Z,CONTRIBUTOR,,0,pydata/xarray/pulls/8723,"<!-- Feel free to remove check-list items aren't relevant to your change -->

Some outstanding points/decisions brought up by this PR:
- [ ] Confirm type promotion rules and write them out.  As it stands now, if everything is of the same extension array type, it is passed onwards and otherwise is converted to numpy. (related: https://github.com/pydata/xarray/pull/8714)
~- [ ] Acceptance of `plum` as a dispatch method.  Without it, the behavior should be fallen back on from before (cast to `numpy` types).  I am a big fan of dispatching and think it could serve as a model going forward for making support of other data types/arrays more feasible.  The other option, I think, would be to just use the underlying `array` of the `ExtensionDuckArray` class to decide and then have some central registry that serves as the basis for a decorator (like the api for accessors via `_CachedAccessor`).  That being said, the current defaults are quite good so this is a marginal feature, in all likelihood.~
- [ ] Do we allow just pandas `ExtensionArray` directly or can we also allow `Series`?

Possible missing something else! Let me know!

Checklist:
- [x] Closes #8463 and Closes #5287
- [x] Tests added
- [x] User visible changes (including notable bug fixes) are documented in `whats-new.rst`
- [ ] New functions/methods are listed in `api.rst`
","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8723/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull