fix(pyarrow): handle non-positive width in str.zfill

[mkzung]

Description

On the PyArrow backend, Series.str.zfill(width) and Expr.str.zfill(width) crash with pyarrow.lib.ArrowInvalid: Negative buffer resize whenever width <= 0.

The result is built with pc.case_when(...), and one of the branches is pc.utf8_lpad(remaining_chars, width - 1, padding="0"). pc.case_when evaluates every branch eagerly, so for width <= 0 the width - 1 pad length is negative and PyArrow raises before any row is selected.

This handles the two non-positive cases the way the other backends do. A width of 0 is a no-op, since every string is already at least 0 long, so it returns the input unchanged. A negative width raises InvalidOperationError, matching Polars, whose zfill argument is unsigned. PyArrow was the only backend that crashed on either one.

Reproduction (before this change):

import narwhals as nw, pyarrow as pa
s = nw.from_native(pa.table({"a": ["1", "-5", "abc"]}), eager_only=True)["a"]
s.str.zfill(0)  # pyarrow.lib.ArrowInvalid: Negative buffer resize

The regression tests are scoped to PyArrow, since that is the backend that crashed.

What type of PR is this? (check all applicable)

• 💾 Refactor
• ✨ Feature
• 🐛 Bug Fix
• 🔧 Optimization
• 📝 Documentation
• ✅ Test
• 🐳 Other

Related issues

• No existing issue; found while exercising the string namespace on the PyArrow backend.

AI assistance

• No AI tools were used for this PR.
• AI tools were used.

I used an AI coding assistant to help locate the root cause and draft the regression test. I have read, run, and verified every line, and I take full responsibility for the change.

Checklist

• Code follows style guide (ruff)
• Tests added
• Documented the changes (no doc change needed; behaviour matches the documented str.zfill)

[MarcoGorelli]

thanks @mkzung !

If you would rather the Arrow backend raise on a negative width to match Polars
instead of returning unchanged, I am happy to switch.

i think i'd prefer that, could we do that instead please? thanks 🙏

[mkzung]

Done. The Arrow backend now raises InvalidOperationError on a negative width, matching Polars, instead of returning unchanged, and width 0 stays a no-op. I also moved the regression tests to pyarrow only, since Polars' own zfill(0) raises on the older CI versions.

[camriddell]

@MarcoGorelli should we push this check up to narwhals/expr_str.py. If we do that then

1. The error can be raised as early as possible for all backends
2. All implementations will have a uniform error message

If not, then I'm happy with the implementation here.

[mkzung]

Worth adding that the inconsistency is wider than zfill. With a negative width today, pandas returns the string unchanged, Polars raises conversion from 'i128' to 'u64' failed, and pyarrow crashes inside utf8_lpad. pad_start and pad_end do the same thing - on pyarrow they leak ArrowInvalid: Negative buffer resize.

So moving the check up to expr_str/series_str fixes three methods at once and gives every backend the same error. I have it on a branch: validation in Expr.str and Series.str, the Arrow negative-width raise removed (the width == 0 no-op stays, that one is a genuine pyarrow quirk), tests parametrised across backends, full suite green.

mkzung/narwhals@main...mkzung:narwhals:fix/zfill-validate-in-public-layer

Happy to fold it into this PR, or to leave it until you and @MarcoGorelli have settled where the check belongs.