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
1945654275,PR_kwDOAMm_X85c7HL_,8319,Move parallelcompat and chunkmanagers to NamedArray,35968931,closed,0,,,9,2023-10-16T16:34:26Z,2024-02-12T22:09:24Z,2024-02-12T22:09:24Z,MEMBER,,0,pydata/xarray/pulls/8319,"@dcherian I got to this point before realizing that simply moving `parallelcompat.py` over isn't [what it says in the design doc](https://github.com/pydata/xarray/blob/main/design_notes/named_array_design_doc.md#appendix-implementation-details), which instead talks about

> - Could this functionality be left in Xarray proper for now? Alternative array types like JAX also have some notion of ""chunks"" for parallel arrays, but the details differ in a number of ways from the Dask/Cubed.
> - Perhaps variable.chunk/load methods should become functions defined in xarray that convert Variable objects. This is easy so long as xarray can reach in and replace `.data`

I personally think that simply moving parallelcompat makes sense so long as you expect people to use chunked `NamedArray` objects. I see the chunked arrays as special cases of duck arrays, and my understanding is that `NamedArray` is supposed to have full support for duckarrays.

cc @andersy005 

- [x] As requested in #8238
- [ ] ~~Tests added~~
- [ ] ~~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/8319/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull