html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/pull/2384#issuecomment-422535898,https://api.github.com/repos/pydata/xarray/issues/2384,422535898,MDEyOklzc3VlQ29tbWVudDQyMjUzNTg5OA==,5635139,2018-09-18T20:14:04Z,2018-09-18T20:14:04Z,MEMBER,Thank you v much @jsignell ! Both for the excellent code and for bearing with the changes!,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,354324342
https://github.com/pydata/xarray/pull/2384#issuecomment-421171706,https://api.github.com/repos/pydata/xarray/issues/2384,421171706,MDEyOklzc3VlQ29tbWVudDQyMTE3MTcwNg==,5635139,2018-09-13T22:22:44Z,2018-09-13T22:22:44Z,MEMBER,"Sorry I'm late to the party here. @jsignell thank you for the PR!

Pandas has something similar: the `._shallow_copy` method, which accepts optional data to replace the current data.

Ambitious suggestion: given that we already create shallow copies when copying, could `data` become an optional arg to `copy`? I realize it's may be a little surprising to change all the data and still call it a copy, but there's precedent.

Less ambitious: I'd vote to have this as a method. I'm generally partial to methods given their discoverability and namespaces-without-cost. I think the context is clear. OTOH there is precedent with `ones_like` et al.

Naming: I'd vote `labelled_like` > `structured_like`, but not strongly

That said, given my timing, I'd understand if we go forward as-is","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,354324342