issue_comments: 325558564
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/issues/1535#issuecomment-325558564 | https://api.github.com/repos/pydata/xarray/issues/1535 | 325558564 | MDEyOklzc3VlQ29tbWVudDMyNTU1ODU2NA== | 1217238 | 2017-08-29T05:24:35Z | 2017-08-29T05:24:35Z | MEMBER | @fujiisoup is finishing up #1473 (vectorized indexing) but we still have one unresolved concern: existing uses of xarray objects to index other xarray objects will break in some cases, because the behavior of vectorized indexing will depend on dimension names and coordinates on indexer objects. In particular: behavior will change if the indexer object goes along a different dimension than the corresponding dimension of the indexed object (e.g., for Unfortunately, there isn't a good way to deprecate the existing behavior while introducing the new behavior, since the meaning of this type of indexing will change. We could do a deprecation cycle (https://github.com/pydata/xarray/issues/1333), but that will mean delaying this highly useful form of indexing. For what it's worth, I think this the last major breaking change of this type that we will need for xarray. (Though we might choose to do some other clean-ups before the v1.0 release) Are we OK with this breaking change for the 0.10 release? It would be accompanied by a large note under "Breaking changes" in the release notes. (Free to express your opinion with 👍 or 👎 on this comment.) |
{
"total_count": 6,
"+1": 6,
"-1": 0,
"laugh": 0,
"hooray": 0,
"confused": 0,
"heart": 0,
"rocket": 0,
"eyes": 0
} |
253463226 |