Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MyPy doesn't recognize scalar arithmetic for pandas classes #31160

Open
WillAyd opened this issue Jan 20, 2020 · 8 comments
Open

MyPy doesn't recognize scalar arithmetic for pandas classes #31160

WillAyd opened this issue Jan 20, 2020 · 8 comments
Labels
Typing type annotations, mypy/pyright type checking

Comments

@WillAyd
Copy link
Member

WillAyd commented Jan 20, 2020

Something like:

1 + pd.Series([1])

will yield error: Unsupported operand types for + ("int" and "Series") I assume because our arithmetic ops are added at runtime and not statically. Would be nice to support this somehow though

@simonjayhawkins simonjayhawkins added the Typing type annotations, mypy/pyright type checking label Jan 21, 2020
@jorisvandenbossche
Copy link
Member

@WillAyd How can you ever know this "statically" ?
To know if two types can be added up like that, you could need to know if Series.__add__ returns NotImplemented for that type or not, which always seems something run-time dependent?

@WillAyd
Copy link
Member Author

WillAyd commented Jan 21, 2020

It’s not the definition as much as the declaration. So something like add would have to exist statically for my py to recognize. right now we use factory methods at runtime to add that

@jbrockmendel
Copy link
Member

This comes up often enough i wouldn't mind changing our runtime-pinning to something like:

def __add__(self, other)
     return factory_func(self, other, operator.add)

@WillAyd
Copy link
Member Author

WillAyd commented Sep 29, 2020

I don't mind adding these statically. I think talked with @jreback in the past though who may have disagreed so pinging for his input, otherwise would take a PR

@jreback
Copy link
Contributor

jreback commented Sep 30, 2020

yeah ok with doing more static things as it will help with typing

@jorisvandenbossche
Copy link
Member

And apart from typing, it will also result in easier to understand code, I think

@simonjayhawkins
Copy link
Member

the last part of #34869 (comment) is related

yeah ok with doing more static things as it will help with typing

+1

And apart from typing, it will also result in easier to understand code, I think

+1

have started down this route on a few commonly used dynamically added methods, to avoid ignores.

# --------------------------------------------------------------------
# methods that dispatch to array and wrap result in DatetimeIndex
@doc(DatetimeArray.tz_convert)
def tz_convert(self, tz) -> "DatetimeIndex":
arr = self._data.tz_convert(tz)
return type(self)._simple_new(arr, name=self.name)
@doc(DatetimeArray.tz_localize)
def tz_localize(
self, tz, ambiguous="raise", nonexistent="raise"
) -> "DatetimeIndex":
arr = self._data.tz_localize(tz, ambiguous, nonexistent)
return type(self)._simple_new(arr, name=self.name)
@doc(DatetimeArray.to_period)
def to_period(self, freq=None) -> "DatetimeIndex":
arr = self._data.to_period(freq)
return type(self)._simple_new(arr, name=self.name)

# --------------------------------------------------------------------
# methods that dispatch to array and wrap result in PeriodIndex
@doc(PeriodArray.asfreq)
def asfreq(self, freq=None, how: str = "E") -> "PeriodIndex":
arr = self._data.asfreq(freq, how)
return type(self)._simple_new(arr, name=self.name)
# ------------------------------------------------------------------------

when I did the first one I thought it was clearer to include the actual code for clarity, but after adding a couple more, it does look more like boilerplate and @jbrockmendel solution may be better #31160 (comment) Will look again.

@jbrockmendel
Copy link
Member

Our arithmetic ops are no longer added dynamically. Does that solve this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Typing type annotations, mypy/pyright type checking
Projects
None yet
Development

No branches or pull requests

6 participants