pandas read_excel(), DataFrame.iloc[] stubs issues

[DramatikMan]

Environment data

• Language Server version: 2021.7.5
• OS and version: Lubuntu 21.04
• Python version: 3.9.5

Code Snippet / Additional information

pandas.read_excel()

There is no @overload for the first positional argument being something other than str, namely bytes.

@overload
def read_excel(
    filepath: str,

Up-to-date docstrings snippet:

Parameters
----------
io : str, bytes, ExcelFile, xlrd.Book, path object, or file-like object

pandas.DataFrame.iloc[]

There is no @overload for a slice object with ints as an input.

class _iLocIndexerFrame(_iLocIndexer):
    @overload
    def __getitem__(self, idx: Tuple[int, int]) -> Scalar: ...
    @overload
    def __getitem__(self, idx: int) -> Series[Dtype]: ...
    @overload
    def __getitem__(self, idx: Tuple[Union[IndexType, MaskType], int]) -> Series[Dtype]: ...
    @overload
    def __getitem__(self, idx: Tuple[int, Union[IndexType, MaskType]]) -> Series[Dtype]: ...
    @overload
    def __getitem__(self, idx: Union[int, Tuple[Union[IndexType, MaskType], Union[IndexType, MaskType, int]]]) -> DataFrame: ...

Up-to-date docstrings snippet:

Allowed inputs are:

- An integer, e.g. ``5``.
- A list or array of integers, e.g. ``[4, 3, 0]``.
- A slice object with ints, e.g. ``1:7``.

[MapleCCC]

The type stub for pandas bundled with pylance is from microsoft/python-type-stubs. You probably should open an issue there. However, I find the response rate quite low in that repo.

A better approach is to open an issue or even better a PR in pandas itself. The pandas codebase seems to accept progressive addition of type annotations. For example, they accepts a PR to add type annotation for read_html(). Considering that read_excel() bears strong resemblance to read_excel(), your PR will very likely get picked up.

[jakebailey]

We're the maintainers of both repos, so we will see both issue trackers and handle them when we have the opportunity.

Our stubs override what pandas ships (IIRC we are still more type complete, and the effort to have them port our changes back hasn't happened), so we still have to apply fixes in our repo when possible.

I'm pretty sure that iloc slice issue was fixed last week in ce88d83

[MapleCCC]

@jakebailey Thank you for the clarification. I have been having the wrong impression that pylance/pyright treats the type annotations in the original libraries as ground truth, and only uses bundled type stubs as a last resort.

While we are here, I think it's a good idea for pylance to provide a table of which bundled type stub coming from which upstream repo. So that user who encounters errors related to bundled type stubs can go to the correct repo to open an issue, instead of jamming pylance's issue tracker.

For example, I had spent some effort searching around to finally figure out the openpyxl stubs bundled by pylance is actually from https://github.com/MartinThoma/openpyxl-stubs, submit a PR there to fix an issue opened in pylance. Quite a journey. Would be easier if pylance tells us where it pulls each bundled type stubs from.

[jakebailey]

I have been having the wrong impression that pylance/pyright treats the type annotations in the original libraries as ground truth, and only uses bundled type stubs as a last resort.

It only prefers stubs from libraries over typeshed/bundled stubs if the library is py.typed, which pandas isn't. (And I don't think it's ready for that distinction quite yet anyhow.)

[Avasam]

Pandas has been upstreamed and no longer maintained here. https://github.com/pandas-dev/pandas-stubs I think this can be closed.