[feature] Type Hints

[kornerc]

Feature Checklist

• Searched the issues page for similar feature requests

• Read the relevant sections of the documentation

• Browse the repository, tutorials and tests for already existing functionalities

Feature Type

• Adding new functionality to pandapower

• Changing existing functionality in pandapower

• Removing existing functionality in pandapower

Problem Description

pandapower provides type information in the doc-strings e.g.

pandapower/pandapower/create.py

Line 37 in 01d80e6

**f_hz** (float, 50.) - power system frequency in hertz

It would be helpful to also have type hints in the code for function parameters and return types.

Feature Description

Add PEP484 type hints to functions etc.
IDEs like VS Code and PyCharm understand these type hints and can support with linting.

E.g.

def create_empty_network(name="", f_hz=50., sn_mva=1, add_stdtypes=True):
    ...

becomes

def create_empty_network(name: str = "", f_hz: float = 50., sn_mva: float = 1, add_stdtypes: bool = True) -> pandapowerNet:
    ...

Since the smallest Python version currently supported by pandapower is 3.8, it would be needed to stick to type hints compatible with Python 3.8 e.g.

from typing import List
my_list: List[int] = [1, 2, 3]

instead of

my_list: list[int] = [1, 2, 3]

I think it would be sufficient to add type hints to functions which are most frequently used by users e.g. in pandapower/pandapower/create.py for now.

Is there principal interest in this feature?
If yes I can start making PRs for this.

It would also be possible to use static type checking with mypy to validate the type hints but this is fully optional.

Additional Context

No response

Label

• Relevant labels are selected

[Fabsit]

If yes I can start making PRs for this.

it would be highly appreciated! Tag me as reviewer. If possible, work with the pp3 dev release.

[kornerc]

it would be highly appreciated! Tag me as reviewer. If possible, work with the pp3 dev release.

Perfect then I will start with the PR.
Two small questions from my side:

• Is it planned to keep the support for Python 3.8 in pp3, it seems like the support for it is dropped in the branch python_313?
• Which is the pp3 dev release branch; is it the branch develop?

[Fabsit]

yes develop. or does it make sense for you to not support python 3.8 and work directly in python_313?
Regarding which python version are supported in which branch, @vogt31337 or @heckstrahler could you please answer this? Also depending on @kornerc assessment regarding python 3.8.

[vogt31337]

Python 3.8 ended Like 4 months ago: https://endoflife.date/python

I would suggest to not officially support it anymore.
Typing will be A lot of work. I think this will be a Kind of Community effort...

One big question, can you do it smaller pieces? Like maybe File by File? Otherwise Changes in between will lead to a Lot of conflicts...

[kornerc]

Python Version

Python 3.8 ended Like 4 months ago: https://endoflife.date/python

I would suggest to not officially support it anymore.

In that case I would prefer to use features which aren't available in Python 3.8 and would support Python >= 3.9.

For me both is fine, having the branch python_313 as base or develop.
I can wait for the merge of python_313 into develop if this is planned to me merged soon.

The most relevant type hinting features are in my opinion:

3.8

from typing import List, Optional

def foo(l: List[int], o: Optional[int] = None) -> int:
    return sum(l) + (o or 0)

3.9

from typing import Optional

def foo(l: list[int], o: Optional[int] = None) -> int:
    return sum(l) + (o or 0)

3.10

def foo(l: list[int], o: int | None = None) -> int:
    return sum(l) + (o or 0)

Split PR size

One big question, can you do it smaller pieces? Like maybe File by File? Otherwise Changes in between will lead to a Lot of conflicts...

Yes I totally agree.
Packing this in a single PR is 1) lots of work, 2) unlikely to be ever finished, 3) difficult to review, and 4) will result - as you already pointed out- in many merge conflicts.

I would start with the functions most often used by the users e.g. pandapower/pandapower/create.py and make a single PRs per file (or groups of files) which have a digestible size.
Based on that we can also make adjustments in the case we should face certain pitfalls early on.