issue_comments

If it's easier, a method for "transpose these dimensions to the order which makes the data contiguous" would meet my needs.

I'm happy in principle to work on either feature, but when I've looked into contributing to xarray before, I've been a bit overwhelmed by complexity - I think I'm currently using a pretty small fragment of what it can do.

@max-sixty - I certainly want to avoid copying the data unless it's necessary. But I'd like to present the axes in the 'real' memory order, from the largest stride to the smallest.

I appreciate that it shouldn't matter for program logic, but it can definitely matter for performance, and I know some users are going to use axes by position rather than by name, so I do consider it an important part of the API.

Thanks, it makes sense that dimension order conceptually doesn't matter so much once they're labelled. Though I'd say that as Xarray has public APIs for accessing dimensions by position, changing how something like .unstack() orders them probably is a breaking change.

I'm providing an API for other people to access data as a DataArray, and I'd like to have the dimensions in the order that makes it C contiguous, as a hint about what kinds of operations will be efficient. I know some users also go 'what is this complicated thing?' and extract the numpy array from it, in which case the order is more important.

So another option that would work for me would be a separate method that rearranges the dimensions to the order that makes the array C contiguous.

OK, I've xfailed it.

OK, looks like the test failure now is real. Let me know if you want me to comment out the relevant line so the tests pass.

Nope. I don't understand the error, though it looks like astropy has had something similar: https://github.com/astropy/astropy/issues/6424

Also black is now failing on a number of files not affected here.

Merged master, crossing fingers that fixes it.

As in my other PR, one suggested addition causes a test failure, and I've put that in the last commit.

Yes, sorry, it dropped off my radar. I've implemented all the changes suggested above.

The datetime64 & timedelta64 cases don't roundtrip completely, so there are test failures. I've added these in a separate commit at the end, so it's easy to cut that back out if you prefer.

I just made ipython/ipython#10186 - if you've got time, could you try with that branch and see if it works without the config?

I'm still a bit puzzled why this is necessary. I couldn't reproduce it when building the docs locally.

Thanks @shoyer :+1:

Thanks, I've applied all of your suggestions.

OK, I've excluded that combination from Travis.

OK, let's see how that goes.

Outstanding issue: What to do with unicode data (the native str type on Python 3 is unicode). The SciPy netcdf module doesn't attempt to handle unicode, so I wrote some code to encode unicode to bytes before storing it in scipy. That means, however, that the roundtrip doesn't work, because loading the data again gives bytes, not str.

The netCDF4 module appears to handle this by just decoding any string data it finds to unicode, without considering what it's intended to be.

Options: - Decode all string data to unicode on load. This is consistent with what netCDF already does. - Store the fact that the data was encoded in an attribute in the file. If that attribute is present, decode it again on load. - Don't decode any data, and change all the scipy roundtrip tests to expect that data comes back as bytes.

I'm not familiar enough with netCDF and how it's used to know what makes sense here.

Work in progress: https://github.com/takluyver/xray/tree/py3