Add type stub files to python's typeshed

[max-sixty]

Same issue as xarray: pydata/xarray#771, resolved with pydata/xarray#773.

OK to do the same to NDFrame?

[jreback]

why? these ops already have been defined for quite some time

this is a downstream issue

[max-sixty]

They are monkey patched rather than defined explicitly (I think - tell me if I'm off), and so IDEs / static code checkers can't resolve them.

Check out the xarray PR...

[jreback]

as I said all of these are defined in line

[max-sixty]

Help me understand where I'm mistaken here... I see them being defined here for Series: https://github.com/pydata/pandas/blob/master/pandas/core/series.py#L3001

...and there's no __add__ method explicitly defined in line (i.e. with def __add__ or __add__ = on the Series class or any of its parents.

[jreback]

these are all defined in ops

I am unclear as to the problem

py charm has used pandas for years

[max-sixty]

Ok but pause for a moment on what I'm trying to get across, or ask if you need more info.

Because the methods aren't defined in line, PyCharm can't evaluate that pandas objects have the methods. For example:

So in xarray I added them in line, and PyCharm then can resolve them, even though they are never hit at run time.

[jreback]

and is this new?

this has never been reported before

I would say this is a bug in py charm

[jreback]

fixing a symptom is very rarely s good idea

[max-sixty]

It is not new. I imagine that it hasn't been raised before because it's only very mildly annoying - although for a lot of people. Either that, or my setup is somehow different.

Re the symptom - generally I couldn't agree more - in this case I can also empathize with a static code checker trying to resolve whether a method exists. And I think of this as more like an interface definition than a hack. FWIW I submitted an issue to PyCharm here: https://youtrack.jetbrains.com/issue/PY-18095

Another option would be to define skeletons here (I think this is how numpy does it), but I haven't gone into detail as to how that works.

[jreback]

ok if they ever get back to you then either post here or open a new issue

do you use PyCharm? no one I know ever used it / very heavyweight

[max-sixty]

We use PyCharm for dev, Jupyter for exploration. I find PyCharm great actually - navigation, some code checking, refactoring.

You're on vim / emacs?

[jreback]

emacs

[max-sixty]

@jreback I heard back from PyCharm https://youtrack.jetbrains.com/issue/PY-18095

They suggest putting together .pyi files on the standard python type repo: https://github.com/python/typeshed

What are your views on this generally? Not sure it's the measured solution for the specific issue we were having, but a reasonable broader issue nonetheless.

[jreback]

yes we should probably do this as it's the way to hint to the ch checkers. no idea how long / tricky this is

[max-sixty]

OK @jreback, shall I start a new issue or do you want to reopen this and I'll rename it?

[smontanaro]

What's the status of this? It's not clear this ticket is still open. The last comment on March 2 indicated that it was reopened, but... what does the "(!) Open" button mean? Are there some stubs laying about I can test, or should I just punt and run mypy's stubgen over my installed Pandas code?

[jreback]

@smontanaro open means its open! nothing has been done on this, you are welcome to contribute fixes though!

[smontanaro]

Thanks... Eh, I was thinking that was a button (given its color matching the obvious "Comment" button, and didn't hover my mouse to check that it wasn't. I can't push anything out of my work account, but will at least try and add some stubgen-generated .pyi files from home. I will also try to figure out why stubgen fails on some modules. Watch this space.

[frankcarey]

I'm looking into this now.. Looks like you can generate stubs with the following script that's installed with mypy.. https://github.com/python/mypy/blob/master/mypy/stubgen.py

[OliverSieweke]

See also data-science-types which has started work in that direction.

[mroeschke]

Since we have #28142 going about the same issue. Going to close this issue in favor of that one.