GH-55263: [Python][Annotations] Add internal types and core data structures by rok · Pull Request #55264 · apache/arrow

rok · 2026-10-26T11:25:15Z

Rationale for this change

This is the next step in adding type annotations to PyArrow (#32609). It merges #49103 (internal type system stubs) and #49193 (core data structures) because the two depend on each other and can't be type checked separately.

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Was AI used for this PR?

In accordance to the AI generation guidelines, please disclose below whether and how AI was used in this PR.

PR code and description written by:

Human
AI

Reviewed before submission by:

Human
AI
Not reviewed

GitHub Issue: [Python][Annotations] Add internal types and Core Data Structures #55263

github-actions · 2026-10-26T11:26:09Z

⚠️ GitHub issue #55263 has been automatically assigned in GitHub to PR creator.

AlenkaF · 2026-10-27T05:54:04Z

Thanks for continuing to push this forward Rok! I think this PR is a great next step and is quite clear to review.

I have checked out the PR locally and started with running type checkers (mypy, pyright and ty). mypy and ty emit no errors or warnings, but pyright does emit reportMissingImports and reportMissingModuleSource which get fixed with adding _compute.pyi placeholder (similar to existing io.pyi) and reportMissingModuleSource = false under [tool.pyright] in pyproject.toml.

The reason for these warnings and errors in pyright is that locally I have editable pyarrow install where scikit-build-core puts the .so files in a separate folder (not python/pyarrow) without __init__.py and pyright can't find them. As we do not need the compiled modules for the type checkers, I think it is fine to use reportMissingModuleSource = false.

I propose to push the changes directly if we agree the additions makes sense.

Meanwhile I will continue with running the pyarrow-stubs tests.

AlenkaF · 2026-10-27T12:56:51Z

I have run pytest pyarrow-stubs/tests, no errors found. I have looked through the tests also and tried to break some, everything looks good. I think the tests are easy to follow while still cover a lot of different angles.

I have also run mypy's stubtest with stubtest pyarrow.lib --concise --mypy-config-file pyproject.toml. All of the reported discrepancies are cases of "... is not present in stub" with majority of them being stubs that are not yet included in this PR (scalars, io, etc.). Part of these are also Type_* stubs, for example pyarrow.lib.Type_UINT8. As we already have TypesEnum defined here, might it make sense to also include Type_* stubs now? (I am not inclined towards adding them, just wondering).

Besides the reports mentioned above which will be fixed in subsequent PRs, stubtest did found one bug in pyarrow:

pyarrow.lib.Decima32Array is not present in stub

Note missing "L" in "Decimal". I will work on the fix for this now and would suggest to add it as part of this PR. Can commit directly, if that is ok.

tadeja · 2026-10-27T12:59:01Z

I've run pre-commit run --hook-stage manual python-stubs --all-files which currently uses pyarrow==26.0.0 wheel modules in site-packages/pyarrow, and got all passing (Python Stubs Lint (ruff), Python Stubs Type Check (mypy/pyright/ty)) - except for ruff-format which requires 10 files to be reformatted, fyi @rok
Python Stubs Format (ruff)...............................................Failed

Running on editable dev build 27, with pyright==1.1.414 in my conda env, I also hit errors reportMissingImports and warnings reportMissingModuleSource - Suggested changes by @AlenkaF sound good and seem to work fine for me locally.

rok · 2026-10-27T13:40:54Z

Thanks for continuing to push this forward Rok! I think this PR is a great next step and is quite clear to review.

I have checked out the PR locally and started with running type checkers (mypy, pyright and ty). mypy and ty emit no errors or warnings, but pyright does emit reportMissingImports and reportMissingModuleSource which get fixed with adding _compute.pyi placeholder (similar to existing io.pyi) and reportMissingModuleSource = false under [tool.pyright] in pyproject.toml.

The reason for these warnings and errors in pyright is that locally I have editable pyarrow install where scikit-build-core puts the .so files in a separate folder (not python/pyarrow) without __init__.py and pyright can't find them. As we do not need the compiled modules for the type checkers, I think it is fine to use reportMissingModuleSource = false.

I propose to push the changes directly if we agree the additions makes sense.

That makes sense and please go for it. I think we should aim for pyproject.toml setting to be as close to the state we want to maintain as possible. So far I've tried to exclude modules that are not covered and ignore as few things as possible. reportMissingModuleSource = false seems good, we will want to challenge it when we have complete coverage.

Part of these are also Type_* stubs, for example pyarrow.lib.Type_UINT8. As we already have TypesEnum defined here, might it make sense to also include Type_* stubs now? (I am not inclined towards adding them, just wondering).

Huh. I've never noticed these were missing. Given we're not really using them as types I'd skip them if we can.

Besides the reports mentioned above which will be fixed in subsequent PRs, stubtest did found one bug in pyarrow:
pyarrow.lib.Decima32Array is not present in stub
Note missing "L" in "Decimal". I will work on the fix for this now and would suggest to add it as part of this PR. Can commit directly, if that is ok.

Huh. Let's do the fix as separate PR, but also include a fix here? (And we'll just rebase over the actual fix on main)

I've run pre-commit run --hook-stage manual python-stubs --all-files which currently uses pyarrow==26.0.0 wheel modules in site-packages/pyarrow, and got all passing (Python Stubs Lint (ruff), Python Stubs Type Check (mypy/pyright/ty)) - except for ruff-format which requires 10 files to be reformatted, fyi @rok Python Stubs Format (ruff)...............................................Failed

I'm not sure we want (can) bring in ruff as a CI dependency. However we should autoformat before we merge, so we don't do it later and change history for no good reason. So I propose one of you runs the ruff formatter and commits the change into this branch.

AlenkaF · 2026-10-27T14:07:40Z

reportMissingModuleSource = false seems good, we will want to challenge it when we have complete coverage.

I think reportMissingModuleSource will have to stay due to local editable installs. Otherwise I agree, we should ignore as few things as possible.
Will push the commit 👍

Huh. Let's do the fix as separate PR, but also include a fix here? (And we'll just rebase over the actual fix on main)

Sounds good. Will open an issue and a PR and add a fix here also.

AlenkaF · 2026-10-27T14:17:29Z

Part of these are also Type_* stubs, for example pyarrow.lib.Type_UINT8. As we already have TypesEnum defined here, might it make sense to also include Type_* stubs now? (I am not inclined towards adding them, just wondering).

Huh. I've never noticed these were missing. Given we're not really using them as types I'd skip them if we can.

Yeah, they are internal and exposed through TypesEnum which are added to the stubs here. For stubtest we can later add them to allowlist. For the type checkers we will need to work around them once lib stubs loose their def __getattr__(name: str) -> Any: .... Maybe we can revisit this topic later (maybe we see it's easier to simply add them to the stubs)

tadeja · 2026-10-27T15:37:40Z

... ruff-format which requires 10 files to be reformatted, fyi @rok Python Stubs Format (ruff)...............................................Failed

I'm not sure we want (can) bring in ruff as a CI dependency. However we should autoformat before we merge, so we don't do it later and change history for no good reason. So I propose one of you runs the ruff formatter and commits the change into this branch.

Ok, I'll do that reformatting in a bit.

AlenkaF · 2026-10-28T08:05:06Z

I have started with reviewing pyarrow tests with running mypy --check-untyped-defs --warn-unused-ignores pyarrow/tests/test_* and looking at the ignores. The stubs seem to have changed since the last time type checkers were run on pyarrow tests, example:

click for output

$ mypy --check-untyped-defs --warn-unused-ignores pyarrow/tests/test_array.py 
pyarrow/tests/test_array.py:21: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:22: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:25: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:80: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:790: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:986: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:1300: error: List item 3 has incompatible type "None"; expected "int"  [list-item]
pyarrow/tests/test_array.py:1302: error: List item 1 has incompatible type "None"; expected "list[tuple[bytes, int]]"  [list-item]
pyarrow/tests/test_array.py:1313: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:1320: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:1324: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:1348: error: List item 0 has incompatible type "None"; expected "list[tuple[bytes, int]]"  [list-item]
pyarrow/tests/test_array.py:1348: error: List item 1 has incompatible type "None"; expected "list[tuple[bytes, int]]"  [list-item]
pyarrow/tests/test_array.py:1362: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:2513: error: Need type annotation for "buffers" (hint: "buffers: list[<type>] = ...")  [var-annotated]
pyarrow/tests/test_array.py:2539: error: "object" has no attribute "dtype"  [attr-defined]
pyarrow/tests/test_array.py:2541: error: Value of type "object" is not indexable  [index]
pyarrow/tests/test_array.py:2542: error: Value of type "object" is not indexable  [index]
pyarrow/tests/test_array.py:2543: error: Value of type "object" is not indexable  [index]
pyarrow/tests/test_array.py:2885: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:2917: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:2938: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:2939: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:3183: error: Value of type "object" is not indexable  [index]
pyarrow/tests/test_array.py:3299: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:3720: error: Incompatible types in assignment (expression has type "None", variable has type "ndarray[tuple[Any, ...], dtype[Any]]")  [assignment]
pyarrow/tests/test_array.py:3729: error: Value of type "object" is not indexable  [index]
pyarrow/tests/test_array.py:3740: error: Value of type "object" is not indexable  [index]
pyarrow/tests/test_array.py:3817: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:4004: error: Incompatible types in assignment (expression has type "MyArrayInvalid", variable has type "MyArray")  [assignment]
pyarrow/tests/test_array.py:4017: error: Incompatible types in assignment (expression has type "MyArray2", variable has type "MyArray")  [assignment]
pyarrow/tests/test_array.py:4031: error: Incompatible types in assignment (expression has type "MyArray3", variable has type "MyArray")  [assignment]
pyarrow/tests/test_array.py:4095: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:4099: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:4315: error: List item 3 has incompatible type "None"; expected "int"  [list-item]
pyarrow/tests/test_array.py:4319: error: List item 5 has incompatible type "None"; expected "int"  [list-item]
pyarrow/tests/test_array.py:4324: error: List item 2 has incompatible type "None"; expected "int"  [list-item]
pyarrow/tests/test_array.py:4324: error: List item 4 has incompatible type "None"; expected "int"  [list-item]
pyarrow/tests/test_array.py:4395: error: List item 1 has incompatible type "None"; expected "int"  [list-item]
pyarrow/tests/test_array.py:4407: error: List item 0 has incompatible type "None"; expected "int"  [list-item]
Found 40 errors in 1 file (checked 1 source file)

Type checkers are currently configured to skip python/pyarrow folder (too much noise) so the changes are not caught. Maybe we could start with adding mypy --check-untyped-defs --warn-unused-ignores pyarrow/tests/test_* for specific files that can already be type checked.

I propose to temporarily add the mypy command explicitly naming files which bypasses the exclude setting to ci/scripts/python_test_type_annotations.sh. Will also push the updates of ignores in the tests once I go through the ones connected to this PR.

AlenkaF · 2026-10-28T08:27:50Z

Another thing: I can't run pyright on specific files inside an excluded dir. I guess I would need to be running the checks with pyright only locally (with the pyarrow exclude temporarily removed) until the pyarrow/ exclude in pyproject.toml is removed.

AlenkaF · 2026-10-28T08:53:25Z

Oh, I was too fast here. Unfortunately def __getattr__(name: str) -> Any: ... in python/pyarrow-stubs/pyarrow/__init__.pyi makes anything in form of pa.* be Any making lots of correct ignores (in with pytest.raises ... blocks) falsely reported as unused.

Would it make sense to remove # type: ignores from the pyarrow tests for now and add type checking of the tests (with the ignores) after the stubs are in?

I will leave this for discussion and start with reading the stubs and comparing them with the APIs, starting with _types.pyi first.

rok · 2026-10-28T10:34:08Z

Ignore statements not being needed is more likely due to changes to typecheckers than due to changes in stubs. Or they might be needed once we import other parts of the library. Also note camel cased (e.g. reportArgumentType) ignores are likely coming from pyright. So if mypy thinks it's a redundant ignore you might want to check pyright too.

rok · 2026-10-28T10:36:19Z

Oh, I was too fast here. Unfortunately def __getattr__(name: str) -> Any: ... in python/pyarrow-stubs/pyarrow/__init__.pyi makes anything in form of pa.* be Any making lots of correct ignores (in with pytest.raises ... blocks) falsely reported as unused.

Would it make sense to remove # type: ignores from the pyarrow tests for now and add type checking of the tests (with the ignores) after the stubs are in?

Let's rather remove def __getattr__(name: str) -> Any: ... at least for development work? Otherwise we'll just need to add ignores again.

AlenkaF · 2026-10-28T10:43:03Z

OK, agree, when reviewing pyarrow/tests we should remove def __getattr__(name: str) -> Any: ... from python/pyarrow-stubs/pyarrow/__init__.pyi so we keep the ignores and run mypy and pyright (with updated pyproject.toml) so both pass 👍

I plan to do that later and am focusing on reading the stubs currently.

tadeja · 2026-10-28T16:29:14Z

Ehhh... I've fallen into this interesting rabbit hole - There are over 1.5k mypy errors Module not callable in pyarrow/tests because of the change from upstream's zen-xu/pyarrow-stubs having subfolder __lib_pxi to current PR's flat layout without a subfolder (Past discussion rok#45 (comment) was about the naming, but not really why removing subfolder __lib_pxi)

% mypy --check-untyped-defs --warn-unused-ignores pyarrow/tests/test_convert_builtin.py 
pyarrow/tests/test_convert_builtin.py:78: error: Module not callable  [operator]
pyarrow/tests/test_convert_builtin.py:79: error: Module not callable  [operator]
...
pyarrow/tests/test_convert_builtin.py:168: error: Module not callable  [operator]
...
Found 321 errors in 1 file (checked 1 source file)

% mypy --check-untyped-defs --warn-unused-ignores pyarrow/tests/test_*.py
Found 1866 errors in 35 files (checked 44 source files)
% ... | grep -c  "Module not callable"
1562

test_convert_builtin.py:168 : pa.array(...

A stub pyarrow/array.pyi declares pyarrow.array submodule that doesn't exist at runtime because array.pxi gets compiled into lib. Then pa.array, pa.table or pa.scalar can resolve to stub modules instead of functions.
The count of mypy errors may be even higher, depending on module processing order and mypy cache. (optionally run rm -rf .mypy_cache)

So I propose we reintroduce subfolder __lib_pxi/ (or renamed subfolder _lib_pxi/ or just _lib/) in this PR (for files: array.pyi, builder.pyi, config.pyi, device.pyi, error.pyi, io.pyi, memory.pyi, scalar.pyi, table.pyi, tensor.pyi).
Locally that seems to resolve all 1.5k Module not callable errors and still passes type checkers' tests for me.

tadeja · 2026-10-29T15:39:58Z

Just to note: with commit eda3425 stubs array, builder, config, device, error, io, memory, scalar, table, tensor got moved into pyarrow/__lib/ subfolder/subpackage for mypy to not regard pa.array/pa.table/pa.scalar as stub modules anymore and so more than 1500 errors Module not callable in pyarrow/tests no longer show up.

jorisvandenbossche · 2026-10-29T15:56:17Z

@tadeja I suppose the _types.pyi also needs to be moved into the subdirectory (and can then be renamed to types.pyi)?

tadeja · 2026-10-29T16:03:45Z

@jorisvandenbossche oh, yes, I think _types.pyi and _ipc.pyi both still need to be moved but there are some extra steps needed (and @AlenkaF has some work in progress on types at the moment, and I may wait for that)

AlenkaF · 2026-10-30T16:56:48Z

@tadeja @rok I have checked typed.pyi and decided to push a commit (4b97c69) after all =) Instead of suggestions I will post the reasoning behind the changes here:

NumPy is also an optional dependency (next to pandas) so I added # type: ignore[..] there too.
Locally mypy and pyright both pass with only # type: ignore[..] so I removed pyright ignores
ty doesn't honor mypy's # type: ignore[...] and # ty: ignore[unresolved-import] fails if numpy/pandas are installed, so I disabled ty unresolved-import in pyproject.toml instead (mypy and pyright still catch broken imports).
I removed noqa: F401 on the lib import and ruff didn't complain
I have changed some classmethods in stubs as they are defined as static methods in source (types.pxi).
Example: _import_from_c in DataType, Field and Schema.
I propose to use typing_extensions.CapsuleType instead of Any in __arrow_c_schema__.
Claude added a test for this case, I have reviewed and changed it a bit. typing_extensions dependency had to be added.
Note: we should leave the Protocols in _stubs_typing.pyi at Any. Polars' public pl.DataFrame and pl.Series, for example, annotate __arrow_c_stream__ -> object so narrowing the Protocol would reject them
- https://github.com/pola-rs/polars/blob/fe540d641165534f2a5e571234c3ee78d51587ee/py-polars/src/polars/dataframe/frame.py#L1587
- https://github.com/pola-rs/polars/blob/fe540d641165534f2a5e571234c3ee78d51587ee/py-polars/src/polars/series/series.py#L1632
Claude suggested to add a test for Protocols also (under the Table stubs tests, to make sure they do not become to narrow) but I think these should be added later.

KeyValueMetadata stubs do not include keys(), values() and items() stubs because they inherit them from Mapping[bytes, bytes]:
https://github.com/python/typeshed/blob/17cbf254205549ccdcf886fadf8c265e634ad596/stdlib/typing.pyi#L823-L825
but our code overrides all three as generators, not Mapping views (probably so that duplicate keys are kept):

arrow/python/pyarrow/types.pxi

Lines 2409 to 2419 in 9b9fad6

    
           def keys(self): 
        
               for i in range(self.metadata.size()): 
        
                   yield self.metadata.key(i) 
        
           def values(self): 
        
               for i in range(self.metadata.size()): 
        
                   yield self.metadata.value(i) 
        
           def items(self): 
        
               for i in range(self.metadata.size()): 
        
                   yield (self.metadata.key(i), self.metadata.value(i))

I have added overrides to the stubs so they are in sync with runtime and added ignores because of

Return type "Iterator[bytes]" of "keys" incompatible with return type "KeysView[bytes]" in supertype "typing.Mapping" [override]

I have also added a test test_key_value_metadata.
I think code overrides need a separate issue as we might want to decide on changing the overrides in types.pxi KeyValueMetadata class to return Mapping views instead of generators (and to somehow keep support of duplicate keys).

keys_sorted in map_ take bool, None is by truthiness converted to False in Cython but I think it should not be suggested as a possible input so I changed the default from None to False. Same for dictionary().
Included the use of np.typing.DTypeLike for parameter type in from_numpy_dtype https://numpy.org/devdocs/reference/typing.html#numpy.typing.DTypeLike
I have changed the Field methods that returned Self to return Field as the runtime always builds a plain Field via pyarrow_wrap_field.

Future TODO:

string_to_tzinfo, tzinfo_to_string and ensure_metadata are not in the stubs currently (not public). We should add them to the stubtest allowlist at some point or think of adding them to the stubs.

I have run

all 3 type checkers on this file with and without numpy/pandas installed
the tests
ruff linter check

Co-authored-by: Joris Van den Bossche <[email protected]>

jorisvandenbossche · 2026-11-13T09:59:26Z

+class ListArray(BaseListArray):
+    @staticmethod
+    def from_arrays(
+        offsets: Int32Array | Iterable[int | None] | np.ndarray,


I think here the same applies as the BooleanArray -> Array discussion we had for the mask argument. IMO we have to annotate this with a generic Array, to avoid people to have to cast their pyarrow array objects (since those will often not be inferred to the exact sub-type)

(and the same for all the Int32Array/Int64Array usage below)

(and I don't know what the good solution is long term. Ideally you would be able to express something like "this argument can be Array, but if you know its subtype, it has to be Int64Array and not something else", but no idea if that is possible)

Actually, I also quickly checked the code for the exact runtime behaviour, and eg in ListArray.from_arrays, we do _offsets = asarray(offsets, type='int32') on the input argument for offsets. So strictly speaking, even Int32Array is not correct if we had perfect inference of Array subtypes. Because it is perfectly fine to pass an int64 array, and it will be cast to int32 at runtime.

In this case we could just make a wide union then. Pyarrow-stubs uses overloads https://github.com/zen-xu/pyarrow-stubs/blob/d92217fe71ff56e86c0125175b488b0d486a3a3e/pyarrow-stubs/__lib_pxi/array.pyi#L2433-L2512. Could we express this with generics?

The overloads are for the values (to try to infer the values type of the ListArray), not for offsets, I think?

And with a wide union, do you mean include both like Array | Int32Array | ..? (my naive assumption about typing logic is that this would be useless compared to just Array)

The overloads are for the values (to try to infer the values type of the ListArray), not for offsets, I think?

Ah yes, indeed.

And with a wide union, do you mean include both like Array | Int32Array | ..? (my naive assumption about typing logic is that this would be useless compared to just Array)

By wide union I mean as wide a type that we can have that's not Array. pyarrow-stubs uses Int32Array | list[int] which seems too narrow.

Ah, that meaning of wide ;) Understood now.

Indeed both parts in Int32Array | list[int] is too narrow, I think this should be something like Array | Iterable[int] (and even the int in Iterable might give problems if you pass eg a numpy array? We should add tests for those)

Pushed bc94a18, please check if it makes sense.

Plus I did additional 66d8661 to narrow the list from_arrays masks from Mask to Array | None as runtime accepts only boolean Array (and not ndarray, also not ChunkedArray)

Add type annotation stubs for compute, _compute, _compute_docstring, and _acero modules. These are the stubs of apacheGH-49201 as they were, at their original paths. The type checker accommodations that apacheGH-49201 made in compute.py, acero.py and the PyArrow tests are left out, as the type checkers no longer run on pyarrow/ (see apacheGH-55264).

Move the stubs to the flat pyarrow-stubs/ layout and drop the generics: plain classes and unions instead of TypeVars and Array[Scalar[...]]. - Array arguments accept any Array or ChunkedArray, since pa.array() and most of the API return plain Array instances. The return types still name the kind of array where the function determines it. The scalar classes are imported from pyarrow.__lib.scalar, as placeholders (Any) until scalar.pyi is annotated. - Fix the signatures that stubtest reports against the runtime, e.g. the arguments without defaults, parameter names and positional-only dunders. Remove CumulativeSumOptions, Function.kernels and the reflected Expression operators, which don't exist or raise TypeError at runtime, and the stub-only Expression methods for the tests. - Rename _compute_docstring.pyi to _compute_docstrings.pyi to match the runtime module, and remove _perform_join and _filter_table from _acero.pyi, which are defined in acero.py. - Add the functions and options added since: hypot, modulo, remainder, inverse_permutation, scatter, search_sorted and their options, and per-key null placement in sort keys. - Type check pyarrow.compute and pyarrow._compute instead of treating them as Any, and add type annotation tests for them.

Add type annotation stubs for compute, _compute, _compute_docstring, and _acero modules. These are the stubs of apacheGH-49201 as they were, at their original paths. The type checker accommodations that apacheGH-49201 made in compute.py, acero.py and the PyArrow tests are left out, as the type checkers no longer run on pyarrow/ (see apacheGH-55264).

Move the stubs to the flat pyarrow-stubs/ layout and drop the generics: plain classes and unions instead of TypeVars and Array[Scalar[...]]. - Array arguments accept any Array or ChunkedArray, since pa.array() and most of the API return plain Array instances. The return types still name the kind of array where the function determines it. The scalar classes are imported from pyarrow.__lib.scalar, as placeholders (Any) until scalar.pyi is annotated. - Fix the signatures that stubtest reports against the runtime, e.g. the arguments without defaults, parameter names and positional-only dunders. Remove CumulativeSumOptions, Function.kernels and the reflected Expression operators, which don't exist or raise TypeError at runtime, and the stub-only Expression methods for the tests. - Rename _compute_docstring.pyi to _compute_docstrings.pyi to match the runtime module, and remove _perform_join and _filter_table from _acero.pyi, which are defined in acero.py. - Add the functions and options added since: hypot, modulo, remainder, inverse_permutation, scatter, search_sorted and their options, and per-key null placement in sort keys. - Type check pyarrow.compute and pyarrow._compute instead of treating them as Any, and add type annotation tests for them.

…al types Squash of apache#55264 (5a026a0) on top of main, to check the stacked compute stubs against it. Not for merging.

Add type annotation stubs for compute, _compute, _compute_docstring, and _acero modules. These are the stubs of apacheGH-49201 as they were, at their original paths. The type checker accommodations that apacheGH-49201 made in compute.py, acero.py and the PyArrow tests are left out, as the type checkers no longer run on pyarrow/ (see apacheGH-55264).

Move the stubs to the flat pyarrow-stubs/ layout and drop the generics: plain classes and unions instead of TypeVars and Array[Scalar[...]]. - Array arguments accept any Array or ChunkedArray, since pa.array() and most of the API return plain Array instances. The return types still name the kind of array where the function determines it. The scalar classes are imported from pyarrow.__lib.scalar, as placeholders (Any) until scalar.pyi is annotated. - Fix the signatures that stubtest reports against the runtime, e.g. the arguments without defaults, parameter names and positional-only dunders. Remove CumulativeSumOptions, Function.kernels and the reflected Expression operators, which don't exist or raise TypeError at runtime, and the stub-only Expression methods for the tests. - Rename _compute_docstring.pyi to _compute_docstrings.pyi to match the runtime module, and remove _perform_join and _filter_table from _acero.pyi, which are defined in acero.py. - Add the functions and options added since: hypot, modulo, remainder, inverse_permutation, scatter, search_sorted and their options, and per-key null placement in sort keys. - Type check pyarrow.compute and pyarrow._compute instead of treating them as Any, and add type annotation tests for them.

pa.array() is annotated as returning the base Array, so parameters typed as Int32Array, Int8Array or BooleanArray forced users to cast. Annotate them as Array, and widen run ends to what the runtime accepts. DictionaryArray.from_arrays never accepts an Arrow array as mask, so drop BooleanArray there.

Annotate pyarrow.compute, pyarrow._compute, pyarrow._acero and pyarrow._compute_docstrings, following the approach of apacheGH-55264: plain classes and unions instead of generics, in the flat pyarrow-stubs/ layout. - Array arguments accept any Array or ChunkedArray, since pa.array() and most of the API return plain Array instances. The return types name the kind of array where the function determines it. The scalar classes are placeholders (Any) until scalar.pyi is annotated. - The signatures match the runtime, as checked by stubtest. - pyarrow.compute and pyarrow._compute are type checked instead of being treated as Any. - Add type annotation tests for the compute and Acero stubs.

…al types Squash of apache#55264 (bc94a18) on top of main. The compute stubs in the next commit build on it; this commit goes away once that pull request is merged.

Annotate pyarrow.compute, pyarrow._compute, pyarrow._acero and pyarrow._compute_docstrings, following the approach of apacheGH-55264: plain classes and unions instead of generics, in the flat pyarrow-stubs/ layout. - Array arguments accept any Array or ChunkedArray, since pa.array() and most of the API return plain Array instances. The return types name the kind of array where the function determines it. The scalar classes are placeholders (Any) until scalar.pyi is annotated. - The signatures match the runtime, as checked by stubtest. - pyarrow.compute and pyarrow._compute are type checked instead of being treated as Any. - Add type annotation tests for the compute and Acero stubs.

github-actions Bot added the awaiting committer review label Oct 26, 2026

github-actions Bot added Component: Python Component: Documentation labels Oct 26, 2026

AlenkaF mentioned this pull request Oct 27, 2026

[Python] Typo in Decimal32Array definition in array.pxi #55285

Closed

jorisvandenbossche reviewed Oct 29, 2026

View reviewed changes

Comment thread python/pyarrow-stubs/pyarrow/__lib/array.pyi Resolved

github-actions Bot added awaiting changes and removed awaiting committer review labels Oct 29, 2026

tadeja added a commit to rok/arrow that referenced this pull request Oct 29, 2026

Move compat.pyi and pandas_shim.pyi to __lib/ like in apache#55264

abc4724

tadeja mentioned this pull request Oct 29, 2026

GH-49198: [Python][Annotations] Flight, CUDA and other modules #49205

Draft

AlenkaF reviewed Nov 12, 2026

View reviewed changes

Comment thread .pre-commit-config.yaml Resolved

AlenkaF reviewed Nov 12, 2026

View reviewed changes

Comment thread docs/source/developers/python/development.rst Resolved

AlenkaF reviewed Nov 12, 2026

View reviewed changes

Comment thread docs/source/developers/python/development.rst Resolved

tadeja and others added 2 commits November 13, 2026 08:51

Apply suggestion from @jorisvandenbossche

157090e

Co-authored-by: Joris Van den Bossche <[email protected]>

Add 2 overloads to _Tabular __getitem__

fc6fb83

jorisvandenbossche reviewed Nov 13, 2026

View reviewed changes

AlenkaF and others added 3 commits November 13, 2026 11:51

Remove note from ty section in the docs

4f0e1d1

Update docs

247ec99

Update .pre-commit-config.yaml

eb7485d

rok mentioned this pull request Nov 13, 2026

GH-49194: [Python][Annotations] Compute module (rebased on GH-55263) rok/arrow#65

Closed

Use Array next to Iterable for clarity

fbf55e6

AFOliveira mentioned this pull request Nov 13, 2026

GH-55486: [Python] Make test_asarray run and update it to the current Scalar API #55585

Open

4 of 5 tasks

Fix an issue found in RecordBatch.set_column

5a026a0

rok added a commit to rok/arrow that referenced this pull request Nov 13, 2026

apacheGH-55263: [Python][Annotations] Core data structures and intern…

044cb36

…al types Squash of apache#55264 (5a026a0) on top of main, to check the stacked compute stubs against it. Not for merging.

tadeja added 3 commits November 13, 2026 15:07

Limit list from_arrays/from_pandas masks, align with runtime

66d8661

Move array() constructor cases to own test

abd654d

Two more overloads for Array/ChunkedArray.__getitem__

97a1f74

rok mentioned this pull request Nov 13, 2026

GH-55596: [Python][Annotations] Add runtime docstrings to the type stubs with docstring-adder #55597

Draft

1 of 5 tasks

Minor mypy docs change

d3db98c

Conversation

rok commented Oct 26, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Was AI used for this PR?

Uh oh!

github-actions Bot commented Oct 26, 2026

Uh oh!

AlenkaF commented Oct 27, 2026

Uh oh!

AlenkaF commented Oct 27, 2026

Uh oh!

tadeja commented Oct 27, 2026

Uh oh!

rok commented Oct 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AlenkaF commented Oct 27, 2026

Uh oh!

AlenkaF commented Oct 27, 2026

Uh oh!

tadeja commented Oct 27, 2026

Uh oh!

AlenkaF commented Oct 28, 2026

Uh oh!

AlenkaF commented Oct 28, 2026

Uh oh!

AlenkaF commented Oct 28, 2026

Uh oh!

rok commented Oct 28, 2026

Uh oh!

rok commented Oct 28, 2026

Uh oh!

AlenkaF commented Oct 28, 2026

Uh oh!

tadeja commented Oct 28, 2026

Uh oh!

tadeja commented Oct 29, 2026

Uh oh!

jorisvandenbossche commented Oct 29, 2026

Uh oh!

tadeja commented Oct 29, 2026

Uh oh!

Uh oh!

AlenkaF commented Oct 30, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tadeja Nov 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

rok commented Oct 26, 2026 •

edited by github-actions Bot

Loading

rok commented Oct 27, 2026 •

edited

Loading

tadeja Nov 13, 2026 •

edited

Loading