issue_comments: 798798781

Thanks a lot for the full response!

I forgot to reply to one question of yours — let's use this PR, if you want to replace the current code with the gen_ops branch.

It takes precedence only during type checking as the source for static type information.

Ofc, I see, there's no type information in the .py file. Out of interest, was there a reason we don't make a single .py file with the typing info too? (tbc, no need to redo!)

Unfortunately we have to define them both ways for typing purposes.

Thanks for the comments — even better to have them in the code. I still have one question — if we remove a line like this, does mypy not recognize it can use the method on a Dataset?

python class DataArrayOpsMixin: def __add__(self, other: T_Dataset) -> T_Dataset: ...

With NoReturn mypy correctly errors in that case. Without NoReturn mypy incorrectly infers the result to be Variable.

That's surprising — I wonder where it's getting that information from. I would have expected that it wouldn't be able to find any compatible implementation of a GroupBy + Variable.

There seem to be quite some open issues here with no indication they currently are actively working on fixing them. I am not using PyCharm myself, but as it is widely used I would also expect quite some xarray users to be using it.

I would vote not to prioritize a tool if it's not compatible — this code will last for a long time, and I expect PyCharm will catch up to the language specs soon.

For these unary ops with simple type hints if would probably work but for most other methods with multiple overloads the typing ecosystem is not yet mature enough. In this issue I have commented on it.

Great, thank you