Helping with Python syntax and refactoring regression reviews

[yangfan-yf-yf]

I would like to help with ongoing regression reviews for Python syntax support and refactoring correctness.

My merged contributions include the Python 3.13 classifier and avoiding autoimport syntax-error output. In my review of #874, I ran the rename/inline tests and checked the generated code at runtime. That identified two non-generic type-alias cases where inlining turns working code into AttributeError or NameError.

I can take a small queue of reports and follow-up changes in this area:

• Reproduce syntax and refactoring issues against the relevant revisions.
• Add focused regression cases and check that the transformed code preserves runtime behavior.
• Review follow-up fixes and record which Python versions and test cases were actually checked.

Would it be useful for me to take on this area regularly? If so, which existing issue or PR should I prioritize, and what review scope would help most?

[lieryan]

Hi @yangfan-yf-yf, thank you for the interest in contributing to rope.

It is usually not going to be necessary to individually review regression on particular python versions, we have Github Actions configured to run on all supported Python versions for every pull requests before they are merged. However, spotting and writing any missing test cases, especially in cases where the result of a refactoring operation might produce different semantic in different python version would definitely be helpful as there are currently no automated checks for these.

Currently, most rope test cases only check the result of the refactoring against a fixed expected string, which may or may not be a valid transformation. The test cases generally do not check that the transformed code would actually match the runtime semantic of the original code.

Rope currently do not have a lot of explicit support for type hints and issues like those you identified in #874 are definitely things that rope didn't have to need to handle previously as there's currently not much consideration for lazy evaluation context within how rope currently treats type hints. This will definitely be an area that exposes a number of bugs as lazy evaluation is starting to become the norm and expected by default by many codebases.