Type of "apply" is partially unknown

[JanEricNitschke]

I am again interested in getting some pyright strict warnings fixed that i get due to a lack of type parameters. This time for df.apply. However this already has a lot of overloads and i do not yet fully understand all of them.

Firstly i do not quite understand this one:

   @overload
    def apply(
        self,
        f: Callable[..., Mapping],
        axis: AxisIndex = ...,
        raw: _bool = ...,
        result_type: None = ...,
        args=...,
        **kwargs,
    ) -> Series: ...

that would be something like

def returns_dict(x: pd.Series) -> dict[str, int]:
    return {"col4": 7, "col5": 8}

df = pd.DataFrame(data={"col1": [1, 2], "col2": [3, 4], "col3": [5, 6]})
print(df.apply(returns_dict))

Which just gives me an object series.

col1    {'col4': 7, 'col5': 8}
col2    {'col4': 7, 'col5': 8}
col3    {'col4': 7, 'col5': 8}

is that really the intended thing here? In that case that one could just go from taking a Mapping -> Series to Mapping[Any, Any] -> Series[Any].

All the ones that just return a dataframe should probably also have Series[Any] (or the equivalent for other generics).

For all overloads that take a

ListLikeExceptSeriesAndStr = TypeVar(
    "ListLikeExceptSeriesAndStr", MutableSequence, np.ndarray, tuple, Index
)

and return a series i think one could probably try to parametrize that further and have the series again be Series[S1]. But bounds in a typevar cant be generic themselves.

[Dr-Irv]

We can only use Series[S1] as a return type if we know that the input type is also Series[S1]. My hypothesis here is that wherever we just use Series in the stubs without specifying the associated type, we could just replace that with Series[Any], and then you'd get strict mode to work better.

[JanEricNitschke]

Yeah, replacing every Unknown that pyright reports with Any would fix most issues with strict mode. I am currently just doing that bit by bit as i am encountering them in my own project and also checking if there are any spots missed where there could be a more constrained one.

[Dr-Irv]

Yeah, replacing every Unknown that pyright reports with Any would fix most issues with strict mode. I am currently just doing that bit by bit as i am encountering them in my own project and also checking if there are any spots missed where there could be a more constrained one.

If we really want to add better support for strict mode, we could add something in the CI, but I haven't had the time to figure out how to set up the github workflows/actions to handle 2 different pyproject.toml files.

[JanEricNitschke]

Ill try to have a look if i have time

[JanEricNitschke]

Simplest case would probably to make a separate CI job that deletes the normal pyproject.toml and either generates a second right there or renames/moves another on in the repo before initializing the environment.

[JanEricNitschke]

I have created a CI configuration here: #954