Skip to content

GH-55263: [Python][Annotations] Add internal types and core data structures - #55264

Draft
rok wants to merge 93 commits into
apache:mainfrom
rok:pyarrow-stubs-pr3-core-data-sans-generic
Draft

GH-55263: [Python][Annotations] Add internal types and core data structures#55264
rok wants to merge 93 commits into
apache:mainfrom
rok:pyarrow-stubs-pr3-core-data-sans-generic

Conversation

@rok

@rok rok commented Oct 26, 2026 •
edited by github-actions Bot
Loading

Copy link
Copy Markdown
Member

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-actions

github-actions Bot commented Oct 26, 2026

Copy link
Copy Markdown

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

@AlenkaF

AlenkaF commented Oct 27, 2026

Copy link
Copy Markdown
Member

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

AlenkaF commented Oct 27, 2026

Copy link
Copy Markdown
Member

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

tadeja commented Oct 27, 2026

Copy link
Copy Markdown
Member

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

rok commented Oct 27, 2026 •
edited
Loading

Copy link
Copy Markdown
Member Author

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

AlenkaF commented Oct 27, 2026

Copy link
Copy Markdown
Member

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

AlenkaF commented Oct 27, 2026

Copy link
Copy Markdown
Member

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)

@AlenkaF AlenkaF mentioned this pull request Oct 27, 2026
Closed
@tadeja

tadeja commented Oct 27, 2026

Copy link
Copy Markdown
Member

... 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

AlenkaF commented Oct 28, 2026

Copy link
Copy Markdown
Member

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

AlenkaF commented Oct 28, 2026

Copy link
Copy Markdown
Member

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

AlenkaF commented Oct 28, 2026

Copy link
Copy Markdown
Member

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

rok commented Oct 28, 2026

Copy link
Copy Markdown
Member Author

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

rok commented Oct 28, 2026

Copy link
Copy Markdown
Member Author

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

AlenkaF commented Oct 28, 2026

Copy link
Copy Markdown
Member

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

tadeja commented Oct 28, 2026

Copy link
Copy Markdown
Member

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

tadeja commented Oct 29, 2026

Copy link
Copy Markdown
Member

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

jorisvandenbossche commented Oct 29, 2026

Copy link
Copy Markdown
Member

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

@tadeja

tadeja commented Oct 29, 2026

Copy link
Copy Markdown
Member

@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)

tadeja added a commit to rok/arrow that referenced this pull request Oct 29, 2026
@tadeja
Move compat.pyi and pandas_shim.pyi to __lib/ like in apache#55264
abc4724
@tadeja tadeja mentioned this pull request Oct 29, 2026
Draft
@AlenkaF

AlenkaF commented Oct 30, 2026

Copy link
Copy Markdown
Member

@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

    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

@tadeja

tadeja commented Nov 10, 2026

Copy link
Copy Markdown
Member

test_array.py: commit 5ea9439 to resolve the latest 'unused-ignore' errors (after all the "layout" changes by @rok)

Expand for error lines 

python % mypy pyarrow-stubs pyarrow/tests/test_array.py
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:2878: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:2910: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:2931: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:2932: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:3292: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:3810: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:4088: error: Unused "type: ignore" comment  [unused-ignore]
pyarrow/tests/test_array.py:4092: error: Unused "type: ignore" comment  [unused-ignore]
Found 11 errors in 1 file (checked 19 source files)

-->

% mypy pyarrow-stubs pyarrow/tests/test_array.py  
Success: no issues found in 19 source files

@tadeja

tadeja commented Nov 10, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

fyi @AlenkaF, @rok, with latest bb913a8 I've just removed/updated unused-ignores for all other pyarrow/tests/test_*.py in this PR, should be no hiccups for your workflow because of it 🤞 :)

=> 12 unneeded ignores removed, 26 ignores mostly changed from # type: ignore[...] to specific # pyright: ignore[reportArgumentType] (mypy doesn't but pyright still needs them). Also updated the line cuda_chunked_array so ignore isn't needed
Tests pass.

Expand for errors before bb913a8

python % mypy pyarrow-stubs pyarrow/tests/test_table.py
pyarrow/tests/test_table.py:815: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:836: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:1230: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:1265: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:1714: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:1735: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:2132: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:2138: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:2270: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:2421: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:2526: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:2543: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:2747: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:2750: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:3817: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:4074: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_table.py:4273: error: Unused "type: ignore" comment [unused-ignore]
Found 17 errors in 1 file (checked 19 source files)

python % mypy pyarrow-stubs pyarrow/tests/test_types.py
pyarrow/tests/test_types.py:478: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_types.py:486: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_types.py:755: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_types.py:758: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_types.py:885: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_types.py:974: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_types.py:1152: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_types.py:1154: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_types.py:1156: error: Unused "type: ignore" comment [unused-ignore]
Found 9 errors in 1 file (checked 19 source files)

python % mypy pyarrow-stubs pyarrow/tests/test_convert_builtin.py
pyarrow/tests/test_convert_builtin.py:168: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_convert_builtin.py:2134: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_convert_builtin.py:2135: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_convert_builtin.py:2543: error: Unused "type: ignore[call-arg, arg-type]" comment [unused-ignore]
pyarrow/tests/test_convert_builtin.py:2545: error: Unused "type: ignore[call-arg, arg-type]" comment [unused-ignore]
Found 5 errors in 1 file (checked 19 source files)

python % mypy pyarrow-stubs pyarrow/tests/test_schema.py
pyarrow/tests/test_schema.py:256: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_schema.py:541: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_schema.py:587: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_schema.py:783: error: Unused "type: ignore" comment [unused-ignore]
Found 4 errors in 1 file (checked 19 source files)

python % mypy pyarrow-stubs pyarrow/tests/test_device.py
pyarrow/tests/test_device.py:70: error: Unused "type: ignore" comment [unused-ignore]
pyarrow/tests/test_device.py:73: error: Unused "type: ignore" comment [unused-ignore]
Found 2 errors in 1 file (checked 19 source files)

---> Success: no issues found in 19 source files

rok added 6 commits November 10, 2026 13:35
@rok
Clean up the type stubs
17e3a08 
Remove the unused helper types from _stubs_typing, add the missing annotations, and import Self and TypeAlias from typing.
@rok
Tidy the type checking setup
e054197 
Run stubtest independently of the working directory, skip the ruff hooks that the Lint job already ran in its type stubs step, and update the type checker comments in pyproject.toml.
@rok
Remove the type checker accommodations from the PyArrow tests
4be907a 
The type checkers don't run on pyarrow/tests, so restore the import fallbacks, ignore comments, casts and isinstance asserts to what they were. Keep the assertions that were missing an assert.
@rok
Import scipy directly in the tensor type stub test
2d3f85c 
Install scipy with the scipy-stubs extra, so the test doesn't need the TYPE_CHECKING import and importorskip.
@rok
Fix the type stub mismatches that stubtest skipped
6ae817e 
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.
@rok
Make the optional import fallbacks in the PyArrow tests pass mypy
ff91bcf
rok
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
@rok
Apply suggestion from @rok
c7d1d97
@AlenkaF
Order imports and unify importing from pyarrow.lib
d027724
@AlenkaF
Fix the CI due to changes in imports
9fc46cd
@AlenkaF
Update Indiced type alias
a8cc1ae
@tadeja
array.pyi: from_pandas type to accept str
96ba7b9
@tadeja
test_array.py: test from_pandas str and take Array indices
0e446fc
@tadeja
array.pyi: from_buffers accept Collection instead of Sequence
faf04a9
@rok
Use TYPE_CHECKING for invalid usage in stub tests and fix review find…
4a899eb 
…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.
@rok
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.
@tadeja
array.pyi: nulls/repeat return Array instead of ArrayLike
d2462bd
@tadeja tadeja mentioned this pull request Nov 10, 2026
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@tadeja tadeja tadeja left review comments
@jorisvandenbossche jorisvandenbossche jorisvandenbossche left review comments
@AlenkaF AlenkaF AlenkaF left review comments
@raulcd raulcd Awaiting requested review from raulcd raulcd will be requested when the pull request is marked ready for review raulcd is a code owner
@assignUser assignUser Awaiting requested review from assignUser assignUser will be requested when the pull request is marked ready for review assignUser is a code owner
@jonkeane jonkeane Awaiting requested review from jonkeane jonkeane will be requested when the pull request is marked ready for review jonkeane is a code owner
@kou kou Awaiting requested review from kou kou will be requested when the pull request is marked ready for review kou is a code owner
Copilot code review Copilot
Copilot will automatically review once the pull request is marked ready for review

Assignees

No one assigned

Labels

Component: Documentation Component: Python

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@rok @AlenkaF @tadeja @jorisvandenbossche @raulcd