`.sel` with a bare number silently selects by a different scale on a coordinate in degrees or percent
还没有人认领这个 Issue。
评估
调研方向
Start by reading PintIndex.sel and conversion.convert_indexer_units, then trace how array_convert_units handles bare numbers for index coordinates. Compare selection on scaled units such as degree and percent with radian and dimensionless, and review the existing indexer conversion tests. Done means the behavior is explicitly resolved and covered by tests for nearest selection and slices.
由索引模型根据 Issue 内容生成。
描述
Hello. Thanks for all your work on pint-xarray, it's awesome.
To be up front, this issue was identified using AI (Claude Opus 5.5) - I was only really looking at quantified data, not coords, but this came up during testing. This doesn't affect me directly but seems like a case for a warning & a docs update (which I'm happy to do if you agree).
Everything below was written & tested using AI. Cheers!
What happened
I understand that a bare number on a quantified index counts as dimensionless, and that a Quantity is the intended label.
The problem is that on a coordinate whose unit is compatible with dimensionless but scaled, such as degree, that rule gives no error or warning, and code that worked before .pint.quantify() silently selects different labels.
import pint_xarray # noqa: F401
import xarray as xr
da = xr.DataArray(
[1.0, 2.0, 3.0],
dims="lat",
coords={"lat": ("lat", [10.0, 20.0, 30.0], {"units": "degree"})},
)
quantified = da.pint.quantify()
print(da.sel(lat=20.0, method="nearest").lat.item()) # 20.0
print(quantified.sel(lat=20.0, method="nearest").lat.item()) # 30.0
print(da.sel(lat=slice(10.0, 20.0)).sizes["lat"]) # 2
print(quantified.sel(lat=slice(10.0, 20.0)).sizes["lat"]) # 0
What I expected
An error, as on a coordinate in metres, where the same mistake is caught:
xr.DataArray(
[1.0, 2.0],
dims="z",
coords={"z": ("z", [10.0, 20.0], {"units": "m"})},
).pint.quantify().sel(z=20.0)
# PintExceptionGroup: Cannot convert from 'dimensionless' (dimensionless) to 'meter' ([length])
Cause
PintIndex.sel passes its labels to conversion.convert_indexer_units, which ends in array_convert_units.
That treats a value that is not a quantity as dimensionless, as its docstring says and test_convert_indexer_units expects, and pint converts dimensionless to degrees by treating the number as radians.
So 20.0 becomes about 1146 degrees before the lookup:
method="nearest"then finds the largest label, 30.- The slice becomes roughly 573 to 1146 degrees, which is empty.
- An exact
.sel(lat=20.0)raisesKeyError, so that case is at least loud.
.sel with a real quantity is correct, as in quantified.sel(lat=20.0 * ureg.degree, method="nearest").
Which units are affected
Run on the same three labels, 10, 20 and 30:
| Coordinate unit | .sel(c=20.0, method="nearest") |
.sel(c=slice(10.0, 20.0)) size |
|---|---|---|
degree |
30 | 0 |
arcminute |
30 | 0 |
percent |
30 | 0 |
radian |
20 | 2 |
dimensionless |
20 | 2 |
| Unquantified, for comparison | 20 | 2 |
The accessor gives a different answer from the index: quantified.pint.sel(lat=20.0, method="nearest") returns the 20 degree row, since it has no indexer units to convert to and strips the coordinate's own.
Latitude and longitude are the common case, since degrees_north is compatible with dimensionless under cf-xarray's registry, and .sel(lat=..., method="nearest") is routine.
Question
Is this the behaviour you intend?
If it is, could the docs say so, since docs/creation.rst still says xarray does not support units in indexes, and nothing I could find says that labels need to be quantities?
If not, one option is to raise for a bare number on an index with a scaled unit, matching what already happens with metres.
Selection on dimensionless and radian could keep working, since the number means the same either way.
Versions
Reproduced in a clean environment with only pint-xarray and xarray installed:
| Package | Version |
|---|---|
| Python | 3.12 |
| pint-xarray | 0.6.1 |
| pint | 0.26.2 |
| xarray | 2026.9.0 |
| numpy | 2.5.4 |
convert_indexer_units and array_convert_units are unchanged on main.
The closest existing issues I found are #303, about method= being rejected, and #276, about indexing with quantities, which both concern a different failure.
- 主要语言
- Python
- 星标
- 120
- 派生
- 17
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
xarray-contrib/pint-xarray 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 48/100
xarray-contrib/pint-xarray#362 · 1 条评论 ·
-
难度 3/5 1-2 天 新手友好度 45/100
xarray-contrib/pint-xarray#361 · 1 条评论 ·
-
难度 3/5 1-2 天 新手友好度 55/100
xarray-contrib/pint-xarray#303 · 3 条评论 ·
-
难度 5/5 一周以上 新手友好度 25/100
xarray-contrib/pint-xarray#271 · 7 条评论 ·
-
难度 5/5 一周以上 新手友好度 20/100
xarray-contrib/pint-xarray#269 · 3 条评论 ·
查看 xarray-contrib/pint-xarray 的全部 Issue
相似的 Issue
-
documentation good first issue
难度 1/5 1 小时以内 新手友好度 88/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
MarketSquare/robotframework-browser#5479 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
endoflife-date/endoflife.date#11561 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
OCA/l10n-brazil#5602 ·
维护者通常 1 天内回复
-
documentation review-2.0.0
难度 2/5 1-3 小时 新手友好度 78/100
dkuenzel/meshcore-home-gateway#106 ·
维护者通常 1 天内回复