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/988#issuecomment-243124532,https://api.github.com/repos/pydata/xarray/issues/988,243124532,MDEyOklzc3VlQ29tbWVudDI0MzEyNDUzMg==,4992424,2016-08-29T13:32:11Z,2016-08-29T13:32:11Z,NONE,"I definitely see the logic with regards to encouraging users to use a context manager, and from the perspective of someone building a third-party library on top of xarray it would be fine. However, I think that from the perspective of an end-user (for example, a scientist) crunching numbers and analyzing data with xarray simply as a convenience library, this produces much too obfuscated code - a standard library import (`contextlib`, which isn't something many scientific coders would regularly use or necessarily know about) and a lot of boiler-plate ""enabling"" the extra features they want in their calculation.

I think your earlier proposal of an `xarray.set_options` is a cleaner and simpler way forward, even if it does have thorns. Do you have any estimate of the performance penalty checking hooks on all xarray objects would incur? 
","{""total_count"": 3, ""+1"": 3, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,173612265