Repository navigation
Pylance error when using a @retry decorator on a function #5035
Description
Asked on SO here with no response.
There are discussions about decorators (python/mypy#1551, python/mypy#3157) that are above my head, but it seems that my use-case was solved.
I'm not sure if I'm reporting a bug or my stupidity, but...
I have a function that runs some code based on random variables. There are some assertion checks on the random variables, so I use a @retry decorator from the retry pip package on the function. Everything works perfectly.
MWE:
from retry import retry
@retry()
def foo():
passHowever, I started using pylance in VS Code with type checking set to "basic" and it's throwing the following error:
Argument of type "() -> None" cannot be assigned to parameter of type "_T@_Decorator"
Type "() -> None" cannot be assigned to type "_T@_Decorator"
The stub being used is https://github.com/python/typeshed/blob/master/stubs/retry/retry/api.pyi
From my beginner's understanding, it looks right, and if I change the second line here from
_T = TypeVar("_T", bound=Callable[..., Any])
_Decorator = Callable[[_T], _T]to
_T = TypeVar("_T", bound=Callable[..., Any])
_Decorator = Callable[[Callable[..., Any]], _T]it's happy, which doesn't make any sense to me, since _T should not be any "stricter" than its bound.
So either there's an issue, or I'm in over my head and completely lost.
I'm new to type checking and trying to learn, so please go easy on me... :)
Activity
srittau commentedon Feb 19, 2021
The stubs look correct to me and mypy accepts the code above. But I may be missing something. Maybe @erictraut can help?
erictraut commentedon Feb 19, 2021
I'm not able to repro the error using Pylance or Pyright. Can you verify that your sample above produces an error for you?
There is one thing I see that wrong with the stub. The
replymethod is annotated to return type_Decorator. This is a generic type alias that accepts a single type parameter. But no type argument is provided in this case. That means it is implicitly_Decorator[Any], which is probably not what was intended. It should probably be_Decorator[_T]. If you enable the "reportMissingTypeArgument" setting in Pylance, it will flag the missing type argument.hauntsaninja commentedon Feb 19, 2021
(Somewhat related https://mail.python.org/archives/list/typing-sig@python.org/thread/DDR2B3USYCQGVXM3ZSK2FASH5YFQGPUV/#DTZG7Y7CO72BMWMGQEFR5PNWFDWQBRO20 )
hudcap commentedon Feb 19, 2021
My humble apologies.
I'm getting the error from my sample code, but only in my workspace.
When I open the file outside the vscode workspace there's no error (see pic below, workspace on left, no workspace on right)
I'll have to figure out why this is happening, but clearly it's not a typeshed issue.
Should I close this or leave it open in light of Eric's comment?
erictraut commentedon Feb 19, 2021
@srittau, @hauntsaninja, Out of curiosity, does mypy or stubtest have a mode where they flag missing type arguments for generic classes or type aliases? If so, would it make sense to enable that in the CI tests for typeshed? This is a common mistake that I see in typeshed stubs.
erictraut commentedon Feb 19, 2021
@hudcap, if you right click on
retryand chooseGo To Declaration, it should take you to the file where theretrysymbol is declared. I'm guessing that you've configured your workspace in a way that the import resolution logic is finding some other module calledretry, but you're expecting it to use the version from the bundled typeshed stubs.hudcap commentedon Feb 19, 2021
@erictraut, it looks like my workspace is pointing to the typeshed stubs in pylance 2021.2.2, but outside the workspace it's pointing to the stubs in 2021.2.3
I restarted vscode and now the error is gone and it's pointing to 2021.2.3 🤦♂️
It must have partially updated in the background and something got messed up, because the stub itself doesn't seem to have changed between those versions.
Thank you everyone!
I'll leave it open for @erictraut's question
srittau commentedon Feb 19, 2021
I am not sure about such an option, but we should consider running the tests through pylance well, anyway.
hauntsaninja commentedon Feb 19, 2021
Yes, mypy has
--disallow-any-generics. I'd love to turn it on, at least for stdlib (as well as the more basic--disallow-untyped-defs). The issue is probably just getting things clean on master.erictraut commentedon Feb 19, 2021
I fixed all of these in stdlib stubs several months ago, but it tends to regress because it's not enforced.
hauntsaninja commentedon Feb 19, 2021
It looks like @srittau added
--disallow-any-genericsa while back in #3288, but it also looks like that maybe isn't doing anything because https://github.com/python/mypy/blob/8780d45507ab1efba33568744967674cce7184d1/mypy/typeanal.py#L354 (which goes back to python/mypy@3549c0e, which is actually before that PR, but maybe not before whatever release?)Note that
--disallow-untyped-defshas a similar issue without--warn-incomplete-stub(see python/mypy#8917 (comment)). This looks all super messy and should be cleaned uperictraut commentedon Feb 19, 2021
Perhaps this issue should be closed and several new issues should be opened:
--disallow-any-genericsand--disallow-untyped-defschecks as they apply to typeshed stubs.Does that sound right?
JelleZijlstra commentedon Feb 21, 2021
I'd love to see #3 (pyright in typeshed CI) happen; is there anything blocking that?
srittau commentedon Feb 22, 2021
@JelleZijlstra Probably just someone that implements this. :) But I have opened #5048 in the meantime.
erictraut commentedon May 2, 2021
I think this issue can be closed. The original issue has been addressed, and pyright is now included in the typeshed CI test suite.