-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type guard is not working properly with walrus conditional #686
Comments
Looking into this more, the behavior is correct. The bug is in the code, not in Pyright. It was not reported as an error in previous versions of Pyright, but a recent bug fix in 1.1.38 changed that. It has nothing to do with type guards or the walrus operator. The same error is identified in this simplified version of the code:
The problem here is that
|
These two are not equivalent at all (that's the point of the import re
def foo(s: str) -> str:
if m := re.fullmatch('(test).+', s):
return m.group(1)
return 'oops' def foo(s: str):
m = re.fullmatch('(test).+', s)
m.group(1) The first one will never execute In [12]: re.Match??
Init signature: re.Match()
Docstring
The result of re.match() and re.search().
Match objects always have a boolean value of True. I've had the same issue with: if rematch := re.match(rf'^\s*{escaped}', string):
_, end = rematch.span() # <-- "span" is not a known member of "None" and even if (rematch := re.match(rf'^\s*{escaped}', string)) is not None:
_, end = rematch.span() # <-- "span" is not a known member of "None" With an if rematch := re.match(rf'^\s*{escaped}', string):
assert rematch is not None
_, end = rematch.span() |
You are correct. These aren't equivalent. Thanks for pointing that out. Re-opening the issue. |
Thank you! |
Type guards were already working for some assignment expressions, but it depended on the type of expression on the right-hand side. I've eliminated the restriction and added your example to the test suite. The fix will be in the next version of Pyright. |
This is now fixed in Pyright 1.1.40, which I just published. |
In issue #474, @alexkoay reported the following bug:
group reports a reportOptionalMemberAccess error under Pyright 1.1.38.
The text was updated successfully, but these errors were encountered: