TYP: IntervalIndex.right/left might be infered as function

[twoertwein]

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• (optional) I have confirmed this bug exists on the master branch of pandas.

---

import pandas as pd

index: pd.IntervalIndex = pd.IntervalIndex.from_arrays([1], [2])
reveal_type(index)
reveal_type(index.right)
index.right.array

pyright

info: Type of "index" is "IntervalIndex"
info: Type of "index.right" is "() -> Index"
error: Cannot access member "array" for type "function"
    Member "array" is unknown (reportFunctionMemberAccess)

mypy

note: Revealed type is 'pandas.core.indexes.interval.IntervalIndex'
note: Revealed type is 'Any'

Output of pd.show_versions()

INSTALLED VERSIONS

commit : 2cb9652
python : 3.9.4.final.0
python-bits : 64
OS : Linux
OS-release : 4.13.0-36-generic
Version : #40~16.04.1-Ubuntu SMP Fri Feb 16 23:25:58 UTC 2018
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.2.4
numpy : 1.20.3
pytz : 2021.1
dateutil : 2.8.1
pip : 21.0.1
setuptools : 52.0.0
Cython : None
pytest : 6.2.4
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : None
IPython : 7.23.1
pandas_datareader: None
bs4 : None
bottleneck : None
fsspec : 2021.05.0
fastparquet : None
gcsfs : None
matplotlib : 3.4.2
numexpr : 2.7.3
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyxlsb : None
s3fs : None
scipy : 1.6.3
sqlalchemy : None
tables : 3.6.1
tabulate : None
xarray : None
xlrd : None
xlwt : None
numba : None

[jbrockmendel]

@simonjayhawkins spitballing here could this be related to cache_readonly not being understood as property-like?

[twoertwein]

cache_readonlywould need to be typed for static type checkers to infer the type of IntervalIndex.right (and of many other wrapped properties).

Unfortunately, it seems that this is currently not really possible since python's built-in property cannot be typed with the current type system in python (python/typeshed#5987 (comment)): type checkers specialize property. This specialization does lead to inconsistencies in the behavior of type checkers, for example with mypy when sub-classing property (python/typeshed#5987 (comment)). cache_readonly is often used in sub-classes, where a super-class uses a property: we need to inherit from property.

I think we have the following options:

1. Do nothing.
2. Wait for mypy to fix its inconsistency and make cache_readonly a subclass of property
3. Follow the idea of make property generic python/typeshed#5987 (comment): write our own property to be a read-only getter (can be typed, no deleter). Make cache_readonly a sub-class of this new property. Replace @property decorators with the new decorator. Probably also add a style check to avoid @property.

Option 2 would be the simplest option, but we might end up waiting a long time. Option 3 is a bit invasive, but it should get the job done.

[hauntsaninja]

The mypy behaviour you described in python/typeshed#5987 (comment) seems clearly suboptimal.

One other way you could workaround this in current code is to lie to mypy:

if typing.TYPE_CHECKING:
    Property = property
else:
    class Property(property): ...

[twoertwein]

I think I tried something like that (simply cache_readonly = property in a stub file) but I need to check that again. I think it resulted on some other errors :)

[twoertwein]

@hauntsaninja I think you are right :) There are still many mypy errors but they are actually legitimate errors. These errors were not triggered before because anything that uses @cache_readonly resulted in type Any.

I think the best way forward is to fix the many type errors uncovered through this and then lie to mypy (cache_readonly = property)

[twoertwein]

I think it would make sense to first fix the following issues #43393, #43391, #43390, #43388, #43387 before trying to fix this issue.

[simonjayhawkins]

These errors were not triggered before because anything that uses @cache_readonly resulted in type Any.

applies to all untyped decorators, xref #33455