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

Match the runtime for the entries of the stubtest allowlist that were marked as stubs to fix: static methods for the from_arrays, from_storage, from_numpy and from_numpy_ndarray constructors, the obj parameter of array(), the integer values of DeviceAllocationType, the signatures of concat_tables and Schema.__getitem__, and no __all__ in pyarrow.types. Remove UnionArray.child, ChunkedArray.data, ChunkedArray.format and Schema.field_by_name, which no longer exist at runtime. Make the type aliases that only the table stubs define private, so that stubtest does not look for them at runtime.

…ings Replace the TYPE_CHECKING_INVALID_USAGE constant of the stub tests with typing.TYPE_CHECKING, in the tests and in the developer documentation. Require the argument of MonthDayNano, and test it together with RunEndEncodedArray.from_buffers, the names of StructArray.from_arrays and tables being unhashable. Move typing_extensions from the test dependency group to requirements-stubs.txt, and link the issue that tracks shipping the stubs in the documentation.

Pass the run-end encoded children as a tuple and remove two unused ignore comments reported by mypy, pyright and ty.

…ix in the next commit)

AlenkaF · 2026-11-11T08:01:16Z

Should have pushed two different commits (one with the test and the other with the fix) but am too used to the -am flag 😄 Hope the change is clear from one commit: 7c1d685 cc @tadeja the change affects array stubs.

AlenkaF · 2026-11-11T08:04:25Z

+    obj: Iterable[Any]
+    | SupportsArrowArray
+    | SupportsArrowDeviceArray
+    | SupportsPyArrowArray,


Array/ChunkedArray are already covered by Iterable[Any] and the protocols, so adding them to stubs isn't needed to pass type checkers. But should we still list them explicitly? They're the most common inputs and listing them makes it clearer to users when in IDE.

Yes, personally I would also include the typical (internal) objects like Array, whenever that is accepted

Plan to unify this in all the files, just waiting for others to chime in.

jorisvandenbossche · 2026-11-11T08:08:28Z

As a meta comment here: could we for this PR test limiting comments to 1 thread and make them inline so GitHub creates a thread. I find replying to long text comments with quotes a lot of work to write and also follow as a reader.

FWIW, I put some of the more general comments intentionally not in an inline comment, because while it nice that github keeps them as a thread together, they are basically impossible to find back later on .. (although maybe this redesigned PR overview page will help with that, who knows 🤷‍♂️ ;))

jorisvandenbossche · 2026-11-11T08:12:37Z

(although maybe this redesigned PR overview page will help with that, who knows 🤷‍♂️ ;))

Nope

jorisvandenbossche · 2026-11-11T09:20:17Z

+mypy only uses the stubs when it checks them too, so pass ``pyarrow-stubs``
+along with any other files you check:
+
+.. code-block::
+
+   $ mypy pyarrow-stubs pyarrow/tests/test_array.py


That is not what I see locally. Running eg mypy pyarrow/tests/test_table.py works just fine and finds the same issues whether I add pyarrow-stubs or not.
(assuming I pass --follow-untyped-imports --check-untyped-defs, otherwise it finds nothing related to pyarrow anyhow)

rok · 2026-11-11T09:29:51Z

As a meta comment here: could we for this PR test limiting comments to 1 thread and make them inline so GitHub creates a thread. I find replying to long text comments with quotes a lot of work to write and also follow as a reader.

FWIW, I put some of the more general comments intentionally not in an inline comment, because while it nice that github keeps them as a thread together, they are basically impossible to find back later on .. (although maybe this redesigned PR overview page will help with that, who knows 🤷‍♂️ ;))

True. Let's then power through this one and try to make future PRs smaller.

jorisvandenbossche · 2026-11-11T09:31:40Z

+    | SupportsArrowDeviceArray
+    | SupportsPyArrowArray,
+    type: Any | None = None,
+    mask: BooleanArray | Iterable[bool] | NDArray[np.bool_] | None = None,


jorisvandenbossche · 2026-11-11T09:41:22Z

+    @staticmethod
+    def from_arrays(
+        offsets: Int32Array | list[int] | list[int | None] | np.ndarray,
+        values: Array | list[Any],


The <>ListArray.from_arrays functions are explicitly typed with list (also in contrast with many other places that accept "values").
But so in practice that is too narrow (eg a numpy array would now be flagged by a type checker?). In practice, this keyword is passed through to pa.array(), and so accepts anything that pa.array() accepts (so at least should be relaxed to include Iterable[Any] instead of list[Any])

And the same goes for offsets (but at least that one includes np.ndarray explicitly)

Also, is there a reason that list[int] | list[int | None] are included both? (instead of just list[int | None])

Fix in 08bccc8. offsets/sizes are now Iterable[int | None]. values (plus keys/items for MapArray) are now Iterable[Any] . So this gets NumPy arrays, tuples, range etc. correctly accepted instead of rejected. Downside: ChunkedArray is accepted although runtime rejects it.

jorisvandenbossche · 2026-11-11T09:49:10Z

+
+_ChunkedArrayConstructorInput: TypeAlias = (
+    Iterable[
+        Iterable[Any]


Related to one of the other comments @AlenkaF made, but I would include Array here as well inside the Iterable (strictly speaking it is covered by Iterable or SupportsArrowArray, but it is probably the most common way to create a chunked array to pass a list of Arrays)

…not typed with CapsuleType

AlenkaF · 2026-11-11T11:25:24Z

Checked error.pyi and opened a separate issue to remove dead code: #55500.

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

rok added 2 commits November 10, 2026 13:35

Make the optional import fallbacks in the PyArrow tests pass mypy

ff91bcf

rok commented Nov 10, 2026

View reviewed changes

Comment thread python/pyproject.toml Resolved

rok and others added 10 commits November 10, 2026 15:30

Apply suggestion from @rok

c7d1d97

Order imports and unify importing from pyarrow.lib

d027724

Fix the CI due to changes in imports

9fc46cd

Update Indiced type alias

a8cc1ae

array.pyi: from_pandas type to accept str

96ba7b9

test_array.py: test from_pandas str and take Array indices

0e446fc

array.pyi: from_buffers accept Collection instead of Sequence

faf04a9

Fix type checker errors in stub tests

91ae655

Pass the run-end encoded children as a tuple and remove two unused ignore comments reported by mypy, pyright and ty.

array.pyi: nulls/repeat return Array instead of ArrayLike

d2462bd

tadeja mentioned this pull request Nov 10, 2026

[Python] test_asarray never runs due to conflicting mark pandas+nopandas #55486

Open

AlenkaF added 2 commits November 11, 2026 07:46

Update test_import_from_c_capsule test

7f59731

Add two ree.from_buffers tests that fail currently but should pass (f…

7c1d685

…ix in the next commit)

AlenkaF reviewed Nov 11, 2026

View reviewed changes

jorisvandenbossche reviewed Nov 11, 2026

View reviewed changes

Ensure we accept objects from external projects in protocol that are …

dce7c2a

…not typed with CapsuleType

tadeja mentioned this pull request Nov 11, 2026

[Python] Let array() return a ChunkedArray only when asked #55499

Open

AlenkaF mentioned this pull request Nov 11, 2026

[Python] Remove the have_signal_refcycle workaround in error.pxi #55500

Open

Review error.pyi

3675813

tadeja added 2 commits November 11, 2026 13:15

array.pyi: array->Array, asarray overload for ChunkedArray

8e26b41

array.pyi: widen list to Iterable in from_arrays, add mask TODO

08bccc8

	mask: BooleanArray \| Iterable[bool] \| NDArray[np.bool_] \| None = None,
	mask: Array \| Iterable[bool] \| NDArray[np.bool_] \| None = None,

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!

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

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!

jorisvandenbossche commented Nov 11, 2026

Uh oh!

jorisvandenbossche commented Nov 11, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rok commented Nov 11, 2026

Uh oh!

Choose a reason for hiding this comment

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!

AlenkaF commented Nov 11, 2026

rok commented Oct 26, 2026 •

edited by github-actions Bot

Loading

rok commented Oct 27, 2026 •

edited

Loading

AlenkaF commented Nov 11, 2026 •

edited

Loading