TYP: mostly io, plotting

[jbrockmendel]

• closes #xxxx
• tests added / passed
• passes black pandas
• passes git diff upstream/master -u -- "*.py" | flake8 --diff
• whatsnew entry

cc @simonjayhawkins can i get your thoughts on two remaining mypy complaints

pandas/io/excel/_base.py:795: error: "Callable[[ExcelWriter], Tuple[str, ...]]" has no attribute "__iter__" (not iterable)  [attr-defined]
pandas/io/stata.py:892: error: unused 'type: ignore' comment

The excel one is because it doesn't recognize

@property
@abstractmethod
def supported_extensions(self) -> Tuple[str, ...]:

as returning Tuple[str, ...]. I expect if that were resolved it would still complain bc subclasses just pin the tuple as a class attribute instead of a property (easy to make a property, but much more verbose which im not wild about)

The stata unused type:ignore becomes used once we remove stata from the setup.cfg exclusion. The only working way I've found to make mypy accept TYPE_MAP: List[Union[int, str]] = list(range(251)) + list("abcd") is with

TYPE_MAP: List[Union[int, str]] = cast(List[Union[int, str]], list(range(251))) + list("abcd")

which i find much less clear than the # type:ignored version.

[jbrockmendel]

punted on issues in the OP, so this should be ready

[simonjayhawkins]

cc @simonjayhawkins can i get your thoughts on two remaining mypy complaints

pandas/io/excel/_base.py:795: error: "Callable[[ExcelWriter], Tuple[str, ...]]" has no attribute "__iter__" (not iterable)  [attr-defined]

see #28339 (comment)

[jbrockmendel]

Makes sense, thanks. Are you OK with the solution here?

[simonjayhawkins]

Makes sense, thanks. Are you OK with the solution here?

from the previous discussion, #28339 (comment)

Sure you could just remove the abstract requirement altogether for supported_extensions and make it a class variable, but that would lose the abstract nature of it.

maybe type: ignore for now and reference the mypy issue, python/mypy#7760

The crux of the issue seems to be python/mypy#7760 (comment)

I guess my real issue then is Python language's lack of notation for abstract class attributes.

The code does work. so we shouldn't really need to change it.

[simonjayhawkins]

The issue here is that the types are not refined by ABCIndexClass?

for a numpy array, this impacts perf.

%timeit np.asarray(axes).ravel()
# 724 ns ± 11.8 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

%timeit axes.ravel()
# 303 ns ± 9.35 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

Is this important?

maybe split the elif into two or ignore till we resolve the ABC issue.

[simonjayhawkins]

or can we cast to Union[np.ndarray, "Index"]

[jbrockmendel]

Index.ravel behavior was just deprecated, so the np.asarray retains the current behavior

[simonjayhawkins]

Thanks @jbrockmendel lgtm