with PEP 561 a package that is written in Python can use inline typings (in the py code files) to support type hints, when installed.
RunnerConfig e.g. already uses the (new and preffered) typing.NamedTuple cublassing-Way in code.
With that, the stubs wouldn't be necessary. (no redundant defining / generating / checking that types are correct / def's match)
Since dpy itself states that it works with Py 3.5~3.8 there is no need for 2.x support (with is EOL anyway).
It would also help with developing in VS Code (witch doesn't read the stubs in the workspace folder).
Since the typings may cause long function signatures, there could (optionally) be a small manual styleguide and/or even a project toml / cfg / ini for flake8/black/... I think especially of line length and style of line breaks and indentation for multiline function definitions.
with PEP 561 a package that is written in Python can use inline typings (in the py code files) to support type hints, when installed.
RunnerConfig
e.g. already uses the (new and preffered)typing.NamedTuple
cublassing-Way in code.With that, the stubs wouldn't be necessary. (no redundant defining / generating / checking that types are correct / def's match) Since dpy itself states that it works with Py 3.5~3.8 there is no need for 2.x support (with is EOL anyway). It would also help with developing in VS Code (witch doesn't read the stubs in the workspace folder).
Since the typings may cause long function signatures, there could (optionally) be a small manual styleguide and/or even a project toml / cfg / ini for flake8/black/... I think especially of line length and style of line breaks and indentation for multiline function definitions.