-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New semantic analyzer: Support idem forward aliases #6404
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
Comments
EDIT: The new behavior is actually correct, see below.
class In:
...
class Out:
In = In # recognized as variable
|
Oh, wait, this is actually correct, by the rules non-indexed assignments at class scope are always variables, so this was previously a false negative, OK back to normal priority. |
Another repro for this issue with a weird error:
fails with
cc @JukkaL |
The examples look meaningless, since the code won't work at runtime. I wonder if the actual code where this comes up is different (involving try/except perhaps). This could also affect the way we'd fix this. |
Yes, the actual code is like try:
C = C
except NameError:
class C:
... Also the second example works without try/except. I think we should fix this before the release since this is actually used in some projects. |
Yes, it would be good to make this better. I'm increasing priority. But even that example seems incomplete, as that will always generate a try:
ModuleNotFoundError = ModuleNotFoundError
except NameError:
class ModuleNotFoundError(Exception):
... The assignment will fail on some Python versions and pass on some. |
Most likely, I don't remember TBH, also |
I did some digging and it looks like this happens sometimes after star imports from C acceleration modules. |
We special case these since a more general fix, such as looking at line numbers of definitions, would break a ton of test cases. Fixes #6404.
This is a follow-up for #6390
This tricky corner case is used in some real code and is supported by old semantic analyzer
But with new analyzer this results in
Invalid type
since the first definition always wins. Probably we just need to special-case this somehow.The text was updated successfully, but these errors were encountered: