PEP 561

[Lunarequest]

currently archinstall is not PEP 561 complaint, if arch install were to become it would allow the end user to make their programs more "static", this would involve creating another package for types. This would allow users to use tools like mypy and pytypes on programs they create.

useful info: https://www.python.org/dev/peps/pep-0561/

[Lunarequest]

the easiest way I have found to make this happen is stubgen, which would generate the files required to be packaged by archinstall for a types package. however this only works if functions and class are type annotated. once I'm done with bios support I'll try and work on this

[Torxed]

I do like the idea of type hinting, and I've started using it a while back. Whenever I have a moment to spare I'll update both the docs as well as the typehints. Since I code in notepad.exe / nano / similar tools from time to time I don't really bother with this stuff to much, but I see the value and I'd love to help towards more usability : )

[Lunarequest]

it should be possible to do this inline in they code using type anotations for example

def foo(bar:str) -> str:
    return bar

[Torxed]

Exactly :D I like that approach hehe. I've started on a few places, but I see now that I've forgotten the return value.

• https://github.com/Torxed/archinstall/blob/aceb0f3e98ea1009474f24cf02fdcf3e5923bcc7/archinstall/lib/output.py#L63

[Lunarequest]

if you have mypy installed it'll throw a fit about return values which is pretty useful

[Torxed]

I hope I'm doing IDE's justice now by doing:

• https://github.com/Torxed/archinstall/blob/99dd9b1fb7856b864d816119f0742950941e97a8/archinstall/lib/profiles.py#L182

I haven't found a way to define multiple return values. That's probably not common practice to return multiple value types depending on criteria's inside the function, and it's probably considered bad practice. But in some functions that's impossible to predict almost and it would be nice to be able to define multiple types hehe.

[Lunarequest]

I think its typing.Optional or typing.Union

[Lunarequest]

in python 3.10 this should be way simpler https://docs.python.org/3.10/whatsnew/3.10.html#pep-604-new-type-union-operator

[f-koehler]

I am really in favor of this. I use type annotations in most of my python code these days and find them really helpful.

Also running mypy via pre-commit/GitHub actions is really useful in my experience. This can catch a lot of bugs and helps the development tools a lot. Also type hints can be added to the documentation automatically

[Lunarequest]

@Torxed this shouldn't be closed, there are still massive code blocks that aren't annotated

[Torxed]

Yepp, this just gets automatically closed if a PR contains fixes and then a reference to the issue. Thank github for this :P

[Torxed]

Just as a reference, PR #846 addresses this