issue_comments: 36216552
This data as json
| 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/pull/20#issuecomment-36216552 | https://api.github.com/repos/pydata/xarray/issues/20 | 36216552 | MDEyOklzc3VlQ29tbWVudDM2MjE2NTUy | 1217238 | 2014-02-27T07:10:03Z | 2014-02-27T07:10:03Z | MEMBER | Notes: 1. DO NOT MERGE -- some of the units tests are currently failing (see below). 2. I decided to rebase to use some of @ebrevdo's recent changes. The discussion on the previous commit can be found here: https://github.com/akleeman/xray/commit/d700eeb4da836cf300e92af6d9dcf17427d67e50 Failing tests: I added an "encoded_dtype" attribute to keep of the original dtype of variables loaded from a netCDF file. Unfortunately, this means most of the round-trip tests currently fail, because no variables have "encoded_dtype" attributes until they are loaded from netCDF files. I think we will need to make some ugly trade-off to get round tripping working both directions, but I'm not yet sure what the best option is. We could: 1. Ignore some specific attributes (like "encoded_dtype") when checking XArray equality. 2. Save these encoding details on XArrays outside of the attributes dict. 3. Add special logic for the round-trip tests to ignore these attributes. FWIW, I think it's OK if we don't preserve data types in the round-trip process, as long as the data itself is equivalent. I'm not entirely opposed to trying, but in general it is very hard to guarantee that serialized/unserialized data is exactly equivalent. There is somewhat of a conflict between preserving the original data (netCDF-like) and representing the data in a sane format in-memory (which should not be exactly like a netCDF). IMHO, we should focus on the later. |
{
"total_count": 0,
"+1": 0,
"-1": 0,
"laugh": 0,
"hooray": 0,
"confused": 0,
"heart": 0,
"rocket": 0,
"eyes": 0
} |
28297980 |