parse_cf loads all data into memory when grid_mapping is missing since .metpy.units checks .data

[jthielen]

In the process of troubleshooting #1705, I followed the code to discover that for all variables without a grid_mapping, MetPy will inadvertently load that variable's data into memory when performing the lat/lon fallback check (since check_axis looks for units, and units checks the type of var.data to see if it is a Quantity, and var.data when a lazy-loaded array ends up loading the data).

While the more direct fix may just be removing the check_axis conditional (which should no longer even be needed after #1651 ...I guess I should have cleared it out then), that wouldn't change the root problem that looking up .metpy.units on a DataArray will load lazy data into memory just because of the type check. Unless there are other suggestions on how to handle this, I would propose

• For 1.0.1, "cheating" and using xarray private API to check against .variable._data instead of .data so that loading isn't triggered
• Propose an upstream change to have a way in the public API to get the actual data object xarray is wrapping even if it is an internal lazy-loader so that our type checks don't have side effects.

[kgoebber]

I'll just confirm that I have run into this issue as well and it took me a while to realize why some loading of remote datasets was failing!

It would be good to have the "cheating" quick fix for now as we work to a more permanent solution. It will help people not have code fail for something it would be very difficult for them to actually know why their code was failing.

[dopplershift]

👍 to getting something in for this release. How low risk is it to use the private API?

[jthielen]

How low risk is it to use the private API?

._data on Variable has been quite stable and I don't see any reason why they would change it, but then again, we've been broken before for relying on xarray's private API.

[dopplershift]

If it's been around awhile, then I guess using that is the best path forward in the interim--we test against git master for a reason. We should then progress on getting an upstream method so we can move to that.

[dopplershift]

#1835 is the tracker issue for a more permanent fix that uses a public API.