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/issues/4490#issuecomment-718346664,https://api.github.com/repos/pydata/xarray/issues/4490,718346664,MDEyOklzc3VlQ29tbWVudDcxODM0NjY2NA==,35919497,2020-10-29T04:07:46Z,2020-10-29T04:07:46Z,COLLABORATOR,"Taking into account the comments in this issue and the calls, I would propose this solution: https://github.com/pydata/xarray/pull/4547","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,715374721
https://github.com/pydata/xarray/issues/4490#issuecomment-704607745,https://api.github.com/repos/pydata/xarray/issues/4490,704607745,MDEyOklzc3VlQ29tbWVudDcwNDYwNzc0NQ==,35919497,2020-10-06T23:35:30Z,2020-10-06T23:35:30Z,COLLABORATOR,"I agree, `open_dataset()` currently has a very long signature that should be changed.
The interface you proposed is obviously clearer, but a class could give a false idea that all backends support all the decoding options listed in the class. I see two other alternatives:
- Instead of a class we could use a dictionary. Pros 1, 2 and 3 would still hold.
- With the interface proposed by @alexamici in #4309 the pros 2 and 3 would still hold and partially 1 (since the open_dataset interface would be greatly simplified). 

For both these proposals, we would lose the autocompletion with the tab but, on the other hand, the user would be relieved of managing a class. 
Finally, I'm not sure that for the user it would be clear the separation between backend_kwargs and decode, since they both contain arguments that will be passed to the backend. Especially if the backend needs more specific decoding options that must be set in backend_kwargs. In this sense, #4309 seems less error-prone.

","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,715374721