Open mttbernardini opened 6 months ago
For mypy
, I guess you would first have to run stubgen
to get better type-checking. Unfortunately the generated stubs also have quite a few errors in them...
So what's missing, I guess, is some manually-checked/-authored pedalboard-stubs
package.
After some more digging, I realized that the stubs are already there of course.
But they are only picked up by mypy when using import pedalboard_native
instead of import pedalboard
.
Is there any reason not to use pedalboard_native
?
Or the other way around: Is there a way to tell mypy that what applies for pedalboard_native
also applies to pedalboard
?
Or the other way around: Is there a way to tell mypy that what applies for pedalboard_native also applies to pedalboard?
According to PEP-561, Python packages containing stubs (i.e. only .pyi
files) should use the -stubs
suffix, quoting the PEP:
The name of the stub package MUST follow the scheme
foopkg-stubs
for type stubs for the package namedfoopkg
So I suppose pedalboard_native
should be named pedalboard-stubs
instead, for typing information to be properly picked by mypy
& co, if that's the package meant to be stubs.
I created a minimum failing example here with a workflow matrix that tests using
mypy
,pyright
,pyre
andpytype
. Of all the type checkers, onlypyright
is able to properly evaluate the snippet without raising errors and properly infer the type ofgain
:Versions:
pedalboard == 0.9.6
mypy == 1.10.0
pyright == 1.1.363
pyre-check == 0.9.21
pytype == 2024.4.11