[Python] Missing `utf8_zfill` in pyarrow.compute to support `str.zfill` behavior

[iabhi4]

Describe the enhancement requested

Feature Request

There’s currently no utf8_zfill kernel in pyarrow.compute, so Python’s str.zfill() behavior can't be reproduced efficiently with Arrow arrays.
While fixing pandas-dev/pandas#61485, I noticed Series.str.zfill() breaks when used on ArrowDtype(pa.string()) because the backend expects a string-padding kernel like utf8_rjust, but nothing exists for zfill. For now, it has to fall back to element-wise Python ops which aren't ideal

Reproduction

import pandas as pd
import pyarrow as pa

s = pd.Series(["A", "AB", "ABC"], dtype=pd.ArrowDtype(pa.string()))
s.str.zfill(3)  # Currently falls back to Python and works via slow path

Expected behavior would be

'A' → '00A'
'AB' → '0AB'
'ABC' → 'ABC' (no change since it's already 3 chars)

What we need

A kernel like pc.utf8_zfill(array, width) that mimics Python’s str.zfill():

• Pad strings with '0' from the left to reach width

• Optional enhancement: handle signs (+, -) same as Python

Why it matters

This will help pandas fully support .str.zfill() for Arrow-backed string arrays, similar to how utf8_rjust, binary_join, etc., already work natively. It'll avoid falling back to slower Python paths and ensure parity with standard Python string behavior

Notes

I’ve temporarily added a TODO in the pandas code to switch over once this is available.

Component(s)

Python

[iabhi4]

take

[pitrou]

Hmm, is utf8_lpad not good enough for this?

>>> pc.utf8_lpad(['ABC'], 10, '0')
<pyarrow.lib.StringArray object at 0x7f2ea343ec20>
[
  "0000000ABC"
]

[iabhi4]

@pitrou That makes sense, utf8_lpad does match Python’s zfill behavior but we are still missing an edge case here. If the string has signs like '-1' or '+1' and we do pc.utf8_lpad(['-1'], 4, '0'), This produces '00-1' which doesn't match Python's '-001'

lpad treats signs as just another character which is not the case with zfill (it preserves the sign and starts padding after that)

Would you recommend layering custom logic on top of utf8_lpad to mimic this behavior, or would it make sense to consider a dedicated utf8_zfill kernel that natively supports Python-style sign handling. That would save us a lot of overhead imo, curious to hear your thoughts

[pitrou]

Yes, we could add a dedicated utf8_zfill kernel. It shouldn't be too difficult to do so if you have C++ skills.
The utf8_lpad function is defined here: https://github.com/apache/arrow/blob/main/cpp/src/arrow/compute/kernels/scalar_string_utf8.cc#L897
The ascii_lpad function, correspondingly, is defined here: https://github.com/apache/arrow/blob/main/cpp/src/arrow/compute/kernels/scalar_string_ascii.cc#L1112

[iabhi4]

Thanks for the pointers @pitrou, I'll take a look and raise a PR shortly