7
High
// The Bug
Fixed pydata/xarray#11373 — 2 line bug-fix that corrects the documented default for constant_values in DataArray.pad from 0 to None.
// Root Cause
The edge case in `class DataArray(` at `xarray/core/dataarray.py` causes incorrect behavior when
a specific input condition is met. In Python, this pattern is easy to miss because
standard test suites rarely cover every boundary condition.
The issue is a documentation mismatch. The docstring for `DataArray.pad` stated that `constant_values` defaults to `0`, but the actual implementation defaults to `None` (which pads with `np.nan`). This discrepancy causes confusion for users reading the API docs to understand padding behavior — they expect zero-filled padding but get NaN-filled results by default.
```python
# What the doc said (incorrect):
# constant_values : scalar, tuple or mapping, default: 0
#
# What the code actually does:
# constant_values defaults to None → pads with np.nan
```
The fix is a surgical change — it addresses exactly the failing condition without
refactoring surrounding code. This minimizes the risk of introducing new bugs.
**Impact**: The bug affects users who hit the specific edge case. For xarray,
this means 2 lines fixes a scenario that could
cause incorrect output, crashes, or silent data corruption depending on the code path.
While this is a documentation fix, documentation bugs are insidious — they erode trust
in the API reference and force users to experimentally verify behavior that should be
stated clearly.
a specific input condition is met. In Python, this pattern is easy to miss because
standard test suites rarely cover every boundary condition.
The issue is a documentation mismatch. The docstring for `DataArray.pad` stated that `constant_values` defaults to `0`, but the actual implementation defaults to `None` (which pads with `np.nan`). This discrepancy causes confusion for users reading the API docs to understand padding behavior — they expect zero-filled padding but get NaN-filled results by default.
```python
# What the doc said (incorrect):
# constant_values : scalar, tuple or mapping, default: 0
#
# What the code actually does:
# constant_values defaults to None → pads with np.nan
```
The fix is a surgical change — it addresses exactly the failing condition without
refactoring surrounding code. This minimizes the risk of introducing new bugs.
**Impact**: The bug affects users who hit the specific edge case. For xarray,
this means 2 lines fixes a scenario that could
cause incorrect output, crashes, or silent data corruption depending on the code path.
While this is a documentation fix, documentation bugs are insidious — they erode trust
in the API reference and force users to experimentally verify behavior that should be
stated clearly.
// The Fix
Diff showing the exact changes made to fix the bug.
@@ -5912,7 +5912,7 @@ class DataArray(
(stat_length,) or int is a shortcut for before = after = statistic
length for all axes.
Default is ``None``, to use the entire axis.
- constant_values : scalar, tuple or mapping of Hashable to tuple, default: 0
+ constant_values : scalar, tuple or mapping of Hashable to tuple, default: None
Used in 'constant'. The values to set the padded values for each
axis.
``{dim_1: (before_1, after_1), ... dim_N: (before_N, after_N)}`` unique
@@ -5921,7 +5921,7 @@ class DataArray(
dimension.
``(constant,)`` or ``constant`` is a shortcut for ``before = after = constant`` for
all dimensions.
- Default is 0.
+ Default is ``None``, pads with ``np.nan``.
end_values : scalar, tuple or mapping of Hashable to tuple, default: 0
Used in 'linear_ramp'. The values used for the ending value of the
linear_ramp and that will form the edge of the padded array.// Pattern & Takeaways
**Pattern**: Edge case in `class DataArray(` — the Python code path was not tested
with the specific input that triggers the failure. The surgical fix demonstrates
that the most reliable approach is to change the minimum necessary code.
**Key insight**: The most predictable bugs are edge cases at input boundaries.
Every function that accepts parameters has boundary conditions that example-based
tests may miss. Code review should focus on: (1) What happens with empty/null input?
(2) What happens at iteration boundaries? (3) What happens with unexpected types?
Documentation bugs form a special category. Unlike logic bugs that crash or produce
wrong output, documentation bugs silently mislead. A docstring saying `default: 0`
when the real default is `None` causes users to write code that works by accident
on some versions and breaks on others. Always verify docstrings against actual
default values during code review.
with the specific input that triggers the failure. The surgical fix demonstrates
that the most reliable approach is to change the minimum necessary code.
**Key insight**: The most predictable bugs are edge cases at input boundaries.
Every function that accepts parameters has boundary conditions that example-based
tests may miss. Code review should focus on: (1) What happens with empty/null input?
(2) What happens at iteration boundaries? (3) What happens with unexpected types?
Documentation bugs form a special category. Unlike logic bugs that crash or produce
wrong output, documentation bugs silently mislead. A docstring saying `default: 0`
when the real default is `None` causes users to write code that works by accident
on some versions and breaks on others. Always verify docstrings against actual
default values during code review.