alexmojaki
3.13 support
First of all It was kind of an accident that I pushed directly into your repository, is it OK?
This is the start of the 3.13 support.
fixes #79
The existing tests work, but there are some open issues:
- ("STORE_FAST_STORE_FAST", "STORE_FAST_LOAD_FAST", "LOAD_FAST_LOAD_FAST") are used to load/store two variables, but they map only to one position of one ast.Name. It is not possible for one bytecode to map to multiple locations. I think there is no other option for us than to accept the fact that we are not able to map this instructions to ast nodes.
- I have only checked the existing tests so far and not searched for new samples.
First of all It was kind of an accident that I pushed directly into your repository, is it OK?
Yes, using a branch instead of a fork is better.
("STORE_FAST_STORE_FAST", "STORE_FAST_LOAD_FAST", "LOAD_FAST_LOAD_FAST") are used to load/store two variables, but they map only to one position of one ast.Name. It is not possible for one bytecode to map to multiple locations. I think there is no other option for us than to accept the fact that we are not able to map this instructions to ast nodes.
This is fine. Like you say, I don't even know what we'd do. But also, identifying ast.Name has barely any value. And I think it should be virtually impossible to actually get hold of a frame paused at that point. I can't see a way for one of those instructions to raise an exception - if they could, what would the Python traceback highlight?
if they could, what would the Python traceback highlight
probably the first name. I think I have a backtrace which could trigger something like this.
def a():
def b():
nonlocal e
e += 1
b()
e = 5
a()
output (Python 3.13.0a3+):
Traceback (most recent call last):
File "/home/frank/projects/executing/codi.py", line 11, in <module>
a()
~^^
File "/home/frank/projects/executing/codi.py", line 7, in a
b()
~^^
File "/home/frank/projects/executing/codi.py", line 5, in b
e += 1
^
NameError: cannot access free variable 'e' where it is not associated with a value in enclosing scope
it is currently the same variable. so no issue here, but it is a backtrace which refers to an ast.Name.
I take it back, this is a LOAD_DEREF. The bytecode is only combined for LOAD_FAST.
found the first cpython 3.13 issue https://github.com/python/cpython/issues/114671
What is the status, please? The second beta of 3.13 should be out today.
I fixed some tests for 3.13.0b1 and it is working for 3.13 now, but the ci is failing for 3.5.
@alexmojaki should we start to deprecate some python versions?
Thank you! With the patch from this PR, I can confirm that the RPM package in Fedora Linux with Python 3.13 builds fine.
I have still some problem with the tests (like https://github.com/python/cpython/issues/120108) but I think that we are on a good way.
@alexmojaki, would prefer a normal merge-commit for this review. The reason is that the different commits are useful to connect the small_samples with the code changes.
I would merge it if it is ok for you.