pandas read_excel(), DataFrame.iloc[] stubs issues about python-type-stubs HOT 5 CLOSED

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.

from python-type-stubs.

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

from python-type-stubs.

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

from python-type-stubs.

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

from python-type-stubs.

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

from python-type-stubs.