TYP: parsers.pyi

[jbrockmendel]

• closes #xxxx
• tests added / passed
• Ensure all linting tests pass, see here for how to run them
• whatsnew entry

[simonjayhawkins]

Thanks @jbrockmendel only partly reviewed. comments so far.

[simonjayhawkins]

str

[simonjayhawkins]

perhaps leave untyped for now unless these can accept any type. (although I accept that these are unused so could in theory accept anything without raising TypeError)

---

from https://github.com/python/typeshed/blob/master/CONTRIBUTING.md#conventions

When adding type hints, avoid using the Any type when possible. Reserve the use of Any for when:

the correct type cannot be expressed in the current type system; and
to avoid Union returns (see above).
Note that Any is not the correct type to use if you want to indicate that some function can accept literally anything: in those cases use object instead.

---

so object is the correct type, unless we want to make these consistent with get_window_bounds signature

[simonjayhawkins]

Suggested change

	def read(self, rows: int | None = None) -> dict[int, ArrayLike]: ...
	def read(self, rows: int | None = ...) -> dict[int, ArrayLike]: ...

[simonjayhawkins]

we want to avoid using Any, maybe could use Hashable. (which is effectively Any for a dictionary key)

this fails with error: Dict entry 0 has incompatible type "List[<nothing>]": "int"; expected "Hashable": "int" [dict-item]

from __future__ import annotations
from typing import Hashable


def func(a: dict[Hashable, int]):
    pass


func({list(): 3})

but this passes mypy checks

from __future__ import annotations
from typing import Any


def func(a: dict[Any, int]):
    pass


func({list(): 3})

although granted you can't create a dict with an unhashable key

Traceback (most recent call last):
  File "/home/simon/t.py", line 9, in <module>
    func({list(): 3})
TypeError: unhashable type: 'list'

[jbrockmendel]

@mroeschke can we rule out getting here with self.index_array being None?

[mroeschke]

For VariableWindowIndexer, yes index_array should not be None

[jreback]

can you merge master

[jbrockmendel]

rebased + green

[simonjayhawkins]

so center could be None according to the docstring, but once passed on to cython would be interpreted as False?

[jbrockmendel]

my impression is that the annotation here is wrong, which im putting an ignore on for now

[simonjayhawkins]

This could be None? does cython include implicit Optional?

[simonjayhawkins]

maybe update docstring. since we have

    # default is 'right'
    if closed is None:
        closed = 'right'

in the code.

[jbrockmendel]

does cython include implicit Optional?

for cdef functions, implicit Optional is always in effect