TYPE: annotate np.dtype
This PR helps with annotating `np.dtype` for `pandas._typing.NpDtype` and
`pandas._typing.DtypeObj` so that type-checker won't throw `Unknown` errors when
accessing `pd.DataFrame[col].dtype`.

Imo we would like `dtype` to be inferred from `DataFrame`, but `Any` will be sufficient
for now.

- [ ] closes #xxxx (Replace xxxx with the Github issue number)
- [ ] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [x] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

Not sure what happened with the cancelled test, so restarting. Builds are timing out occasionally right now > This PR helps with annotating `np.dtype` for `pandas._typing.NpDtype` and
> `pandas._typing.DtypeObj` so that type-checker won't throw `Unknown` errors when
> accessing `pd.DataFrame[col].dtype`.

I assume you use `pyright` with `reportUnknownParameterType` enabled (part of pyright's strict setting)? > > This PR helps with annotating `np.dtype` for `pandas._typing.NpDtype` and
> > `pandas._typing.DtypeObj` so that type-checker won't throw `Unknown` errors when
> > accessing `pd.DataFrame[col].dtype`.
> 
> I assume you use `pyright` with `reportUnknownParameterType` enabled (part of pyright's strict setting)?

That is correct. I don't know what is pandas' stand on supporting pyright. I think pandas is far away from being error-free with pyright's strict settings but ideally, we reach it someday.

You might want to have a look at [pandas-stubs](https://github.com/pandas-dev/pandas-stubs). Pandas-stubs is probably also not compatible with pyright's strict settings but it is much closer :) I think the case with `pandas-stubs` is that if users enable `pyright.analysis.useLibraryCodeForTypes = true`, editors or any LSP GoToDefinition will go to the stubs instead of the source code. I feel that sometimes showing the source code is more useful than the stubs itself.

A way to workaround this issue is to copy the stubs from `pandas-stubs` to `$(pwd)/typings`, but it seems to be a very touch and go solution 😄 

Like you said, we will reach it someday, one commit at a time :) > I think the case with `pandas-stubs` is that if users enable `pyright.analysis.useLibraryCodeForTypes = true`, editors or any LSP GoToDefinition will go to the stubs instead of the source code. I feel that sometimes showing the source code is more useful than the stubs itself.

Feel free to open a feature request at https://github.com/microsoft/pyright/ to maybe have a "go to definition" and "go to implementation" option. I think there are many libraries that have stubs, sounds like a useful feature. This pull request is stale because it has been open for thirty days with no activity. Please [update](https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#updating-your-pull-request) and respond to this comment if you're still interested in working on this. Thanks for the pull request, but it appears to have gone stale. If interested in continuing, please merge in the main branch, address any review comments and/or failing tests, and we can reopen.