-
-
Notifications
You must be signed in to change notification settings - Fork 32k
SystemError for pep695 type parameter with the same name as the inner class #109219
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
Thanks. The second one should be fixed by #109123. I'll have to look into what is causing the SystemError on your first example. |
I spent some time last night trying to get this to work without success. I'll try more later today, but here are my thoughts so far on this example: class name_1[name_4]:
class name_4[name_2](name_4):
name_4 The The cc @carljm, would appreciate if you could see whether you agree with this diagnosis, and if you can see a simple way to implement the desired behavior in the compiler. |
Your analysis looks correct to me! I'll take a look at implementation... |
I suppose the problem is that inside the annotation scope for the inner class, |
A similar example that still reproduces the bug, but simplifies and perhaps clarifies a few things (replace the outer annotation scope with a regular function scope, and use a normal re-definition of the typevar in the class scope instead of circularly naming the inner class the same as the typevar; this example should run successfully rather than raise a NameError):
|
In my latter example, the I haven't quite sorted out yet what should be happening here; I'll come back to it tomorrow. |
I'm using this test case to debug, and focusing on the discrepancy between the behavior with and without the
|
FWIW, I also wrote this Maybe we should commit this, ifdef-ed out by default, similar to the |
#109377 fixes this case. I'm still working through some scenarios to see whether it needs more tweaks to avoid breaking any other case. The fix is to use the symbol flag I think the PR may still need an adjustment to ensure we only do this if the name is bound in an enclosing scope. |
hi, I generated some more examples. I used cpython from commit 21f4e6d. class name_1[**name_0]:
try:
class name_3[name_3](name_4=name_0):
name_0
except {name_0} as name_5:
from name_4 import name_0
else:
pass
finally:
pass
# output:
# Traceback (most recent call last):
# File "/home/frank/projects/pysource-playground/test_code.py", line 6, in <module>
# compile(source,sys.argv[1],"exec")
# SystemError: compiler_lookup_arg(name='name_0') with reftype=3 failed in <generic parameters of name_3>; freevars of code name_3: ('.type_params', 'name_0') class name_1[*name_1]:
async def name_1[**name_0](name_5: name_1, /): # type:
name_1
# output:
# Traceback (most recent call last):
# File "/home/frank/projects/pysource-playground/test_code.py", line 6, in <module>
# compile(source,sys.argv[1],"exec")
# SystemError: compiler_lookup_arg(name='name_1') with reftype=3 failed in <generic parameters of name_1>; freevars of code name_1: ('name_1',) class name_0[name_2]:
(name_2 := name_1)
def name_5[*name_4]() -> name_2: # type: ignoresome text
name_2
# output:
# Traceback (most recent call last):
# File "/home/frank/projects/pysource-playground/test_code.py", line 6, in <module>
# compile(source,sys.argv[1],"exec")
# SystemError: compiler_lookup_arg(name='name_2') with reftype=3 failed in <generic parameters of name_5>; freevars of code name_5: ('name_2',) class name_4[**name_0]:
class name_0[name_4](**name_0):
name_0
# output:
# Traceback (most recent call last):
# File "/home/frank/projects/pysource-playground/test_code.py", line 6, in <module>
# compile(source,sys.argv[1],"exec")
# SystemError: compiler_lookup_arg(name='name_0') with reftype=3 failed in <generic parameters of name_0>; freevars of code name_0: ('.type_params', 'name_0') class name_5[**name_5]:
class name_5[name_1](**name_5):
{name_4: name_4 for name_1 in name_3 if name_5}
# output:
# Traceback (most recent call last):
# File "/home/frank/projects/pysource-playground/test_code.py", line 6, in <module>
# compile(source,sys.argv[1],"exec")
# SystemError: compiler_lookup_arg(name='name_5') with reftype=3 failed in <generic parameters of name_5>; freevars of code name_5: ('.type_params', 'name_5') class name_0[name_5]:
@(name_5 := 0)
class name_3[*name_4](name_5=name_5):
{name_0 for name_0 in name_4 if name_5}
# output:
# Traceback (most recent call last):
# File "/home/frank/projects/pysource-playground/test_code.py", line 6, in <module>
# compile(source,sys.argv[1],"exec")
# SystemError: compiler_lookup_arg(name='name_5') with reftype=3 failed in <generic parameters of name_3>; freevars of code name_3: ('.type_params', 'name_4', 'name_5') class name_2[*name_0]:
match something:
case {**name_4}:
name_0 = name_3 # type: ignoresome text
with name_0: # type: ignoresome text
class name_2[name_5](name_0):
name_0
# output:
# Traceback (most recent call last):
# File "/home/frank/projects/pysource-playground/test_code.py", line 6, in <module>
# compile(source,sys.argv[1],"exec")
# SystemError: compiler_lookup_arg(name='name_0') with reftype=3 failed in <generic parameters of name_2>; freevars of code name_2: ('.type_params', 'name_0') Background: I'm currently updating pysource-minimize and pysource-codegen to 3.12. |
@15r10nk Thank you! At first glance just based on the error messages, I suspect these are all the same bug, but I will turn them into test cases and verify the fix handles all of them. |
I tested all of the above cases and #109377 fixes them all; they all compile successfully and then fail as expected at runtime with either |
Co-authored-by: Jelle Zijlstra <[email protected]>
…nGH-109377) (cherry picked from commit 909adb5) Co-authored-by: Carl Meyer <[email protected]> Co-authored-by: Jelle Zijlstra <[email protected]>
…09377) (#109410) gh-109219: propagate free vars through type param scopes (GH-109377) (cherry picked from commit 909adb5) Co-authored-by: Carl Meyer <[email protected]> Co-authored-by: Jelle Zijlstra <[email protected]>
Bug report
Bug description:
The following script shows the SystemError:
output (Python 3.12.0rc2+):
minimizing it further leads some different crashes:
The propably most interresting one is this, which does not look special at all.
output (Python 3.12.0rc2+):
@JelleZijlstra I think this is another one for you. Feel free to create a second issue if you think that they are unrelated.
CPython versions tested on:
3.12
Operating systems tested on:
Linux
Linked PRs
The text was updated successfully, but these errors were encountered: