issue_comments

I'm also relatively sure that if you are willing to put a floor on the version of Matplotlib you support get_window_extent will use it's internally cached renderer (and when we make it uniformly optional we also fixed the cache invalidation logic).

@LunarLanding You may also be interested in awkward array.

That sounds right to me -- a downside of tags is that they can't be (uniquely) expressed in a hierarchical arrangement like those found in HDF5/netCDF4 files.

hdf5 allows for internal links so a datasets and groups can appear in multiple places in the tree. You can even make cycles where groups are in them selves (or their children). The NeXuS format (the xray/neutron one) makes heavy use of this to let data appear both where it "makes sense" from a science point of view from an instrumentation point of view.

I think it is reasonable to expect that netcdf -> xarray -> netcdf always , however I think it is unreasonable to ask that xarray -> netcdf -> xarray will always work. I think it is OK if xarray can express more complex relationship and structures that you can in netcdf (or hdf5 or any existing at-rest format). In an extreme case, consider an interface to a database that returns xarrays 😈 .

This is related to some very recent work we have been doing at NSLS-II, primarily lead by @danielballan .

Is there any motion on this? This come up in relation to akward array today (see https://github.com/scikit-hep/awkward-1.0/issues/749 ).

If xarray goes with the to_numpy spelling as well then all of {pandas, xarray, akwardarray} have the same spelling which is nice from the Matplotlib side of things.

I think the as_ vs to_ distinction the "to_" makes more sense as it gets you out of xarray land and drops you back to raw numpy land.

Can you point me at the configs that upload to the correct place?

It does look like the rackspace server we were pushing to seems to be down. This is more of a @matthew-brett question.

That changes was definitely intentional in BoundaryNorm, but we thought that we were giving a clear error in a case where you used to get a divide by 0 error.

I think we used to implicitly change 1 boundary into a degenerate 2 boundary, I can see the argument that we should be more forgiving, but in boundry norm I'm not sure what that would mean (internally we are going to make every value to either over or under. If you want to support this at the xarray level you should do the [4] -> [4, 4] conversion which will work with all version of Matplotlib.

Thanks to @QuLogic the wheels are building and uploading again.

Those wheels are (I think) built from https://github.com/MacPython/matplotlib-wheels/tree/master . We also use that system to build the wheels we push to pypi, but from the build-X.Y branch. The details of how the travis file needed to be configured changed and we never merged those changes back to master (which we have now done). but the builds are failing with an obscure error ( https://travis-ci.org/github/MacPython/matplotlib-wheels/jobs/697078308 ).

Set the backend to Agg on travis as you don't have a xserever running. You probably want to manually force a draw as well.

What do the failing data sets look like? Does it get easier or harder to find failures if you go up to 10x10? What sort of exceptions are you getting?

You can shove a fair amount of configuration in to pytest.ini to make these opt-in.

@shoyer Thank you :beers:

import xarray as xy ?