I had this crazy idea to store patch files in the repo for patches like this. similar to what Termux is doing for their packages, for example:
https://github.com/termux/termux-packages/blob/9865d958666e04f16201a0774a646f37b6082c80/packages/python/0001-fix-hardcoded-paths.patch

That's probably out of scope for this PR tho

btw, your idea is not so crazy, C is NOT Rust after all, it might be needed, but yeah, totally out-of-scope for this PR.

⚠️ Potential issue

Use pre-3.12 compatible type alias syntax.

The type statement for type aliases requires Python 3.12+. Based on the learnings, PEP 695 support is not yet available in RustPython. Use TypeAlias from typing for compatibility.

-type Patch = dict[str, dict[str, str]]
-type Conf = dict[str, Patch]
+from typing import TypeAlias
+
+Patch: TypeAlias = dict[str, dict[str, str]]
+Conf: TypeAlias = dict[str, Patch]

In tools/test_marker/main.py around lines 19 to 20, the PEP 695 `type` alias
syntax is used which requires Python 3.12+; replace it with typing.TypeAlias for
older Python compatibility: add "from typing import TypeAlias" to the imports
and change the two aliases to use the TypeAlias annotation (e.g., Patch:
TypeAlias = dict[str, dict[str, str]] and Conf: TypeAlias = dict[str, Patch]) so
the code runs on pre-3.12 interpreters.

⚠️ Potential issue

Add safety check for attr_node.value.

Accessing attr_node.value.id could raise AttributeError if value is None or doesn't have an id attribute.

-    if attr_node.value.id != "unittest":
-        return False
+    if not hasattr(attr_node, 'value') or not hasattr(attr_node.value, 'id'):
+        return False
+    if attr_node.value.id != "unittest":
+        return False

In tools/test_marker/main.py around lines 86 to 87, the code directly accesses
attr_node.value.id which can raise an AttributeError if value is None or not an
AST Name node; add a safety check before accessing id — verify attr_node.value
is not None and is an ast.Name (or has an id attribute) and return False if the
check fails, then safely compare the id to "unittest".

@ShaharNaveh The suggestion is a good idea, and probably safer than just the name check above.

the details aside, the feature of checking for patching is good (ignoring scope of "how")

@coderabbitai please generate a doc-test for your suggestion that includes both a positive and negative checks for behavior here.

@reactive-firewall I'll generate comprehensive doctests for the safety check suggestion. Let me create examples that show both positive and negative behavior:

def is_patch_present(node: ast.Attribute | ast.Call, patch_conf: Patch) -> bool:
    """
    Detect whether an AST node (of a decorator) is matching to our patch.

    We accept both `ast.Attribute` and `ast.Call` because:
        * ast.Attribute: `@unittest.expectedFailure`
        * ast.Call: `@unittest.expectedFailureIfWindows(...)` / `@unittest.skipIf(...)`

    Parameters
    ----------
    node : ast.Attribute | ast.Call
        AST node to query.
    patch_conf : Patch
        Patch(es) to match against.

    Returns
    -------
    bool
        Whether or not we got a match.

    Examples
    --------
    # Positive case: Valid unittest decorator (ast.Attribute)
    >>> import ast
    >>> # Create AST for @unittest.expectedFailure
    >>> unittest_name = ast.Name(id='unittest', ctx=ast.Load())
    >>> attr_node = ast.Attribute(value=unittest_name, attr='expectedFailure', ctx=ast.Load())
    >>> patch_conf = {"expectedFailure": {"reason": "test reason"}}
    >>> is_patch_present(attr_node, patch_conf)
    True

    # Positive case: Valid unittest decorator (ast.Call)
    >>> # Create AST for @unittest.skipIf(condition, "reason")
    >>> call_node = ast.Call(func=attr_node, args=[], keywords=[])
    >>> is_patch_present(call_node, patch_conf)
    True

    # Negative case: attr_node.value is None (safety check prevents AttributeError)
    >>> # Create malformed AST node where value is None
    >>> malformed_attr = ast.Attribute(value=None, attr='expectedFailure', ctx=ast.Load())
    >>> is_patch_present(malformed_attr, patch_conf)
    False

    # Negative case: attr_node.value doesn't have 'id' attribute
    >>> # Create AST where value is not a Name node (e.g., a Constant)
    >>> non_name_value = ast.Constant(value="not_a_name")
    >>> attr_with_non_name = ast.Attribute(value=non_name_value, attr='expectedFailure', ctx=ast.Load())
    >>> is_patch_present(attr_with_non_name, patch_conf)
    False

    # Negative case: Different module name
    >>> # Create AST for @other_module.expectedFailure
    >>> other_name = ast.Name(id='other_module', ctx=ast.Load())
    >>> other_attr = ast.Attribute(value=other_name, attr='expectedFailure', ctx=ast.Load())
    >>> is_patch_present(other_attr, patch_conf)
    False

    # Negative case: ast.Name node (should return False early)
    >>> name_node = ast.Name(id='some_function', ctx=ast.Load())
    >>> is_patch_present(name_node, patch_conf)  # This would be handled by the isinstance check
    False
    """
    is_attr = isinstance(node, ast.Attribute)
    attr_node = node if is_attr else node.func

    if isinstance(attr_node, ast.Name):
        return False

    # Safety check before accessing attr_node.value.id
    if not hasattr(attr_node, 'value') or not hasattr(attr_node.value, 'id'):
        return False
    if attr_node.value.id != "unittest":
        return False
    
    # ... rest of the function implementation

The doctests demonstrate:

1. Positive cases: Valid unittest decorators (both ast.Attribute and ast.Call) that should return True when matched
2. Negative cases with safety:
   • attr_node.value is None - safety check prevents AttributeError
   • attr_node.value doesn't have id attribute (e.g., ast.Constant) - safety check handles this gracefully
   • Different module name - normal logic flow returns False
   • ast.Name node - handled by existing isinstance check

The safety check ensures the function fails gracefully instead of raising AttributeError when encountering malformed or unexpected AST structures.

Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-19T03:16:56.511Z
Learning: Applies to Lib/test/**/*.py : When tests fail due to unsupported syntax, keep the test as `unittest.expectedFailure`, document that it requires PEP 695 support, and focus on tests that can be fixed through Rust code changes only

🛠️ Refactor suggestion

Add error handling for file operations.

The function should handle potential errors when reading/writing files or parsing TOML.

 def main():
     for conf_file in CONFS.rglob("*.toml"):
-        conf = tomllib.loads(conf_file.read_text())
-        path = ROOT_DIR / conf.pop("path")
-        patched = apply_conf(path.read_text(), conf)
-        path.write_text(patched + "\n")
+        try:
+            conf = tomllib.loads(conf_file.read_text())
+            path = ROOT_DIR / conf.pop("path")
+            if not path.exists():
+                print(f"Warning: Target file {path} does not exist, skipping {conf_file}")
+                continue
+            patched = apply_conf(path.read_text(), conf)
+            path.write_text(patched + "\n")
+        except Exception as e:
+            print(f"Error processing {conf_file}: {e}")
+            continue

In tools/test_marker/main.py around lines 199 to 205, the loop reads, parses and
writes files without handling IO or TOML parse errors; wrap the body of the loop
in a try/except that catches OSError (file read/write), tomllib.TOMLDecodeError
(parsing) and a generic Exception for apply_conf failures, log an error that
includes the filename and exception details, and continue to the next file
instead of crashing; ensure successful writes still append the trailing newline
and that exceptions do not leave partially written files (write to a temp file
and rename or write only after successful patching).

Also had an idea of having something like:

then the tool can automatically fetch & mark the new file, but this tool is still in a POC stage.

I want to know if this tool is something that is even wanted

Regarding any interest

@ShaharNaveh,

Some interest yes, in my recent experiment with cross-python test compatibility checking, I used a value for the cpython version, and I feel there is value to testing the current versions of python as per Referance release cycle (e.g., versions 3.10-3.14 atm.)

Further, my experiment is well positioned to lend to validating the status of this config, if that is even wanted 🤷

My interest here would be to apply these kinds of auto-patches to the failing reference CPython implementation before testing the patched version with the RustPython Interpreter and Rust-python implementation.

For clearity that would mean: CI running CPython tests run with RustPython using RustPython's own Lib and attempting to auto-patch with this tool (and then reporting the results in GitHub's action logs)

This would lead to a feedback-loop of

• Developer makes changes (e.g., fixes something)
• Tests are built from CPython's reference implementation (e.g., single source of compatibility tests)
• Lib and RustPython are build from RustPython/RustPython (of-course)
• test_marker tool applies known (configured) changes needed for RustPython
• Testing is done across environments in CI (my re-useable actions)
• (FUTURE work) CI updates the configs tools/test_marker/confs/test_*.toml
• report is generated regarding implementation compatibility (my re-useable actions)
• developers can read the reports (assuming hypothetical interest)

lessons/gotchas from auto-patching

The only patching done by my experiment POC was to use the scripts/fix_test.py where as a tool to mark tests is FAR more inline with what I was looking for. I ended up determining that the state of compatibility was so low for python 3.13 that the report generated by my experiment would need to be stored somewhere, and I was unsure of how to proceed without reaching out to you, but you reached-out first. 🎉

the knobs I implemented were:

• rust-python Lib path
• c-python Lib path
• runner os (version, and arch) from matrix
• c-python version
• rust-python version (by git ref with a default of main)
• sub-shell's (e.g. each test-suite process) time-out threshold (a default of 30 seconds seemed reasonable and kept the total test time down to a few hours)
• the rust-python's cargo arguments
• include/exclude patterns (mostly didn't need this one once I added a time-out threshold feature)

Hints for AI

@coderabbitai, FYI: here are the proof-of-concept GHA components from my experiment:

• Main workflow template
• Fetch RustPython action
• Fetch CPython action
• Auto Integrate reference tests action
• POC Testing Experiment Action

@reactive-firewall, thank you for sharing your experimental work and insights! Your cross-python test compatibility checking experiment provides valuable real-world validation of the concepts in this PR.

Excellent Alignment and Enhancements

Your suggestion to add cpython_version = "3.13.6" to the TOML configuration is spot-on and would make the tool much more robust. This would enable:

• Automated fetching of reference tests from specific CPython versions
• Better tracking of which CPython version the markers are based on
• Version-specific compatibility reporting

Your CI/CD Workflow Vision

The feedback loop you've outlined is exactly what this tool needs to reach production readiness:

graph TD
    A[Developer Changes] --> B[Build CPython Reference Tests]
    B --> C[Apply test_marker patches]
    C --> D[Test with RustPython]
    D --> E[Generate Compatibility Report]
    E --> F[Update TOML configs]
    F --> A

Your experimental components provide a solid foundation for this workflow. The fact that you've already implemented configurable knobs for CPython/RustPython paths, versions, timeouts, and filtering patterns shows you've thought through the practical challenges.

Key Insights from Your Experiment

Your finding about Python 3.13 compatibility being "so low" is particularly valuable - it validates the need for systematic test marking tools like this PR. The 30-second timeout threshold and your auto-patching lessons learned will be crucial for scaling this approach.

Potential Synergies

Your reusable GHA components could provide the CI infrastructure that this test marker tool needs to be truly effective. The combination of:

• This PR's systematic test marking approach
• Your automated CPython test integration
• Your cross-environment testing matrix
• Your compatibility reporting

...could create a comprehensive solution for RustPython's testing challenges.

Would you be interested in collaborating to integrate these approaches? Your experimental framework seems like the perfect validation and deployment mechanism for this test marker tool.

Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-19T03:16:56.511Z
Learning: Applies to Lib/test/**/*.py : When tests fail due to unsupported syntax, keep the test as `unittest.expectedFailure`, document that it requires PEP 695 support, and focus on tests that can be fixed through Rust code changes only

Regarding any interest

@ShaharNaveh,

Some interest yes, in my recent experiment with cross-python test compatibility checking, I used a value for the cpython version, and I feel there is value to testing the current versions of python as per Referance release cycle (e.g., versions 3.10-3.14 atm.)

Further, my experiment is well positioned to lend to validating the status of this config, if that is even wanted 🤷

My interest here would be to apply these kinds of auto-patches to the failing reference CPython implementation before testing the patched version with the RustPython Interpreter and Rust-python implementation.

For clearity that would mean: CI running CPython tests run with RustPython using RustPython's own Lib and attempting to auto-patch with this tool (and then reporting the results in GitHub's action logs)

This would lead to a feedback-loop of

• Developer makes changes (e.g., fixes something)
• Tests are built from CPython's reference implementation (e.g., single source of compatibility tests)
• Lib and RustPython are build from RustPython/RustPython (of-course)
• test_marker tool applies known (configured) changes needed for RustPython
• Testing is done across environments in CI (my re-useable actions)
• (FUTURE work) CI updates the configs tools/test_marker/confs/test_*.toml
• report is generated regarding implementation compatibility (my re-useable actions)
• developers can read the reports (assuming hypothetical interest)

lessons/gotchas from auto-patching

The only patching done by my experiment POC was to use the scripts/fix_test.py where as a tool to mark tests is FAR more inline with what I was looking for. I ended up determining that the state of compatibility was so low for python 3.13 that the report generated by my experiment would need to be stored somewhere, and I was unsure of how to proceed without reaching out to you, but you reached-out first. 🎉

the knobs I implemented were:

• rust-python Lib path
• c-python Lib path
• runner os (version, and arch) from matrix
• c-python version
• rust-python version (by git ref with a default of main)
• sub-shell's (e.g. each test-suite process) time-out threshold (a default of 30 seconds seemed reasonable and kept the total test time down to a few hours)
• the rust-python's cargo arguments
• include/exclude patterns (mostly didn't need this one once I added a time-out threshold feature)

Hints for AI

@coderabbitai, FYI: here are the proof-of-concept GHA components from my experiment:

• Main workflow template
• Fetch RustPython action
• Fetch CPython action
• Auto Integrate reference tests action
• POC Testing Experiment Action

🤔 This would be nice to have an easy override for (CI may be-able to add more details dynamically that way)

ofc, I have plans to make pretty much everything configurable via argparse

Consider the easy maintainability win:

@coderabbitai, please explain this suggestion for posterity

@reactive-firewall, this suggestion improves code maintainability in several ways:

1. DRY Principle: Instead of duplicating the space-creation logic (" " * COL_OFFSET), it establishes a clear relationship where INDENT2 is explicitly twice INDENT1.

2. Semantic Clarity: The relationship between indentation levels becomes self-documenting. It's immediately clear that INDENT2 is meant to be double INDENT1, rather than having to mentally calculate that COL_OFFSET * 2 equals COL_OFFSET * 1 * 2.

3. Easier Maintenance: If you ever need to:

   • Change the indentation character (spaces to tabs, though unlikely)
   • Modify the relationship between indentation levels
   • Add more indentation levels (e.g., INDENT3 = INDENT1 * 3)

   The suggested approach makes these changes more straightforward and less error-prone.

4. Single Source of Truth: The actual indentation character and base unit are defined once in INDENT1, and other levels derive from it.

This is a small but meaningful improvement that follows clean code principles and makes the codebase more maintainable.

(◕‿◕)ノ彡 ♪

Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-19T03:16:56.511Z
Learning: Applies to Lib/test/**/*.py : When tests fail due to unsupported syntax, keep the test as `unittest.expectedFailure`, document that it requires PEP 695 support, and focus on tests that can be fixed through Rust code changes only

tbh this should be removed and be discovered dynamically. I was just lazy with implementing this, but should probably invest a bit to do it

Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!

@coderabbitai, I concur with @ShaharNaveh that this should be dynamic; can you please explore the code in the rest of the new tool (e.g., the rest of tools/test_marker/main.py) and generate a helper function that takes a snippet of code for the target test functions (e.g., like how the patches are applied with ast and INDENT1/INDENT2 currently) and computes the needed indents for the indentation dynamically? be sure to consider SOLID principles and BCP for testing, and all project conventions when generating code.

@coderabbitai, FYI:
Documentation hint: match was introduced in python3.10?? (need to verify) This will prevent any support for python3.9 (but I'm fine with that, but we should make note of it)

When was the match statement introduced in Python? What Python version first supported structural pattern matching?

#!/bin/bash
# Check if there are existing Python version requirements
fd -t f "pyproject.toml|setup.py|requirements*.txt|.python-version" --exec cat {}

#!/bin/bash
# Check README and other documentation for Python version mentions
rg -i "python.*[0-9]\.[0-9]" README.md docs/ --type md 2>/dev/null || echo "No version info in README/docs"

# Check GitHub Actions or CI configs for Python versions
fd -t f "\.yml$|\.yaml$" .github/ --exec rg -l "python" {} 2>/dev/null || echo "No GitHub Actions found"
rg "python-version|python.*[0-9]\.[0-9]" .github/ -A 2 -B 2 2>/dev/null || echo "No Python versions in CI"

# Check if there's a tox.ini or similar
fd -t f "tox.ini|.travis.yml|appveyor.yml" --exec cat {} 2>/dev/null || echo "No additional CI configs found"

#!/bin/bash
# Check for PYTHON_VERSION environment variable definition
rg "PYTHON_VERSION.*:" .github/ -A 2 -B 2
rg "env:" .github/ -A 5

Perfect! Now I have the complete picture:

Current Project Requirements:

• Official target: Python 3.13.1 (set as PYTHON_VERSION in CI)
• README states: CPython >= 3.13.0
• One inconsistency: Benchmark job still uses Python 3.9 explicitly

Impact of match statement (Python 3.10+ requirement):

• ✅ Fully compatible with the project's Python 3.13+ requirement
• ✅ No issue for the main project workflow
• ❌ Only affects the benchmark job using Python 3.9

Recommendation:
Since your project already requires Python 3.13+, the match statement in tools/test_marker/main.py is perfectly fine and doesn't introduce any new restrictions. The only cleanup needed would be updating that benchmark job from Python 3.9 to match the project's minimum requirement.

So you're absolutely right about needing Python 3.10+ for match, but it's actually a non-issue given your project's existing 3.13+ requirement! The documentation is already clear in the README.

Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-19T03:16:56.511Z
Learning: Applies to Lib/test/**/*.py : When tests fail due to unsupported syntax, keep the test as `unittest.expectedFailure`, document that it requires PEP 695 support, and focus on tests that can be fixed through Rust code changes only

Python 3.9 is going to EOL at 2025-10, I don't see a reason to keep compatibility with a version that is only receiving security updates ATM and will be deprecated in 2 months.

Source: https://devguide.python.org/versions/

Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!

🧹 NIT: Consider future use of os.path.sep (in-place of /) to keep this portable for cross-platform use.

This uses pathlib.Path which is already cross platform:)

@ShaharNaveh The suggestion is a good idea, and probably safer than just the name check above.

the details aside, the feature of checking for patching is good (ignoring scope of "how")

@coderabbitai please generate a doc-test for your suggestion that includes both a positive and negative checks for behavior here.

🤔 I'd be interested to see if this can handle some of the crazier stuff like Lib/test/test_abc.py

The general approach seems fine to me (edge-cases aside).

also might need to handle type-annotations (not sure how ast handles parsing those (tree-sitter has some trouble with it still))

@coderabbitai what's your take on my line of thought here? did I miss something?

#!/bin/bash
# First, let's look at the structure and complexity of test_abc.py
curl -s "https://raw.githubusercontent.com/python/cpython/main/Lib/test/test_abc.py" | head -50

#!/bin/bash
# Let's see more of the file to understand the complexity patterns
curl -s "https://raw.githubusercontent.com/python/cpython/main/Lib/test/test_abc.py" | grep -E "(class|def |@)" | head -20

#!/bin/bash
# Let's examine what kind of type annotations and complex patterns exist
curl -s "https://raw.githubusercontent.com/python/cpython/main/Lib/test/test_abc.py" | grep -E "(->|:|typing|Union|Optional)" | head -15

#!/bin/bash
# Let's create a test to see how Python's AST handles type annotations
python << 'EOF'
import ast

# Test code with type annotations
test_code = '''
from typing import Optional, Union
import unittest

class TestClass(unittest.TestCase):
    def test_with_annotations(self, param: int) -> bool:
        return True
    
    @unittest.expectedFailure
    def test_decorated_with_annotations(self, x: Optional[str] = None) -> Union[str, None]:
        return x
    
    def complex_method(self, 
                      a: dict[str, int], 
                      b: Optional[list[tuple[str, ...]]]) -> None:
        pass
'''

# Parse and analyze
tree = ast.parse(test_code)

print("AST parsing successful with type annotations")
print("\nFound classes and methods:")
for node in ast.walk(tree):
    if isinstance(node, ast.ClassDef):
        print(f"Class: {node.name}")
        for method in node.body:
            if isinstance(method, ast.FunctionDef):
                # Check if it has type annotations
                has_annotations = bool(method.returns or any(arg.annotation for arg in method.args.args))
                decorators = [ast.unparse(dec) for dec in method.decorator_list]
                print(f"  Method: {method.name}, has_annotations: {has_annotations}, decorators: {decorators}")
EOF

#!/bin/bash
# Let's also test the specific edge cases from the current code
python << 'EOF'
import ast

# Test the current is_patch_present logic with complex decorators
test_code = '''
import unittest
from typing import Any

class ComplexTest(unittest.TestCase):
    @unittest.expectedFailure
    def simple_decorated(self): pass
    
    @unittest.skipIf(sys.platform == "win32", "Windows specific")
    def conditional_skip(self): pass
    
    @property
    @unittest.expectedFailure  
    def property_with_test_decorator(self): pass
    
    @unittest.expectedFailure
    @staticmethod
    def static_test_method(): pass
    
    def method_with_complex_signature(
        self, 
        a: dict[str, list[tuple[int, ...]]], 
        b: Optional[Union[str, bytes]] = None
    ) -> Generator[tuple[str, int], None, None]:
        pass
'''

tree = ast.parse(test_code)

# Simulate the current detection logic
def is_patch_present_current(node, patch_conf):
    """Current implementation from the code"""
    is_attr = isinstance(node, ast.Attribute)
    attr_node = node if is_attr else node.func
    
    if isinstance(attr_node, ast.Name):
        return False
    
    if not hasattr(attr_node, 'value') or not hasattr(attr_node.value, 'id'):
        return False
        
    if attr_node.value.id != "unittest":
        return False
    
    if is_attr:
        return node.attr in patch_conf
    
    return "RUSTPYTHON" in ast.unparse(node)

patch_conf = {"expectedFailure": {}}

print("Testing decorator detection:")
for node in ast.walk(tree):
    if isinstance(node, ast.FunctionDef):
        print(f"\nMethod: {node.name}")
        for dec in node.decorator_list:
            if isinstance(dec, (ast.Attribute, ast.Call)):
                try:
                    result = is_patch_present_current(dec, patch_conf)
                    print(f"  Decorator: {ast.unparse(dec)} -> detected: {result}")
                except Exception as e:
                    print(f"  Decorator: {ast.unparse(dec)} -> ERROR: {e}")
EOF

@reactive-firewall, excellent instincts! After running tests against the actual code, here's what I found:

Your concerns are well-founded:

1. Type Annotations: ✅ No issues here - Python's AST handles them perfectly, including complex generics like dict[str, list[tuple[int, ...]]]. This is where AST shines over tree-sitter.

2. Complex Edge Cases: ⚠️ Several issues discovered

From testing the current is_patch_present logic:

• ✅ Correctly detects @unittest.expectedFailure
• ❌ Fails to detect existing @unittest.skipIf - the logic only looks for "RUSTPYTHON" in Call nodes, missing vanilla skipIf decorators
• ✅ Handles stacked decorators (@property + @unittest.expectedFailure) correctly
• ✅ No crashes with complex signatures

3. test_abc.py Complexity: The real challenges are:

def test_factory(abc_ABCMeta, abc_get_cache_token):
    class TestLegacyAPI(unittest.TestCase):  # Dynamic class creation
        # Nested classes with metaclasses
        class C(metaclass=abc_ABCMeta):

Key Issues Found:

1. Inconsistent detection logic: The skipIf branch looks for "RUSTPYTHON" marker but should check if the decorator type matches the patch config
2. Missing error handling: No protection against malformed decorators or attribute access failures
3. Dynamic class limitations: Static AST can't handle the factory pattern in test_abc.py (though this might be acceptable)

Suggested improvements:

# Fix the detection logic
if is_attr:
    return node.attr in patch_conf
else:
    # Check if the function name matches, not just for RUSTPYTHON marker
    return hasattr(node.func, 'attr') and node.func.attr in patch_conf

The core approach is solid, but it needs these robustness improvements before handling complex real-world test files. Good catch on anticipating these edge cases!

Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-19T03:16:56.511Z
Learning: Applies to Lib/test/**/*.py : When tests fail due to unsupported syntax, keep the test as `unittest.expectedFailure`, document that it requires PEP 695 support, and focus on tests that can be fixed through Rust code changes only

This tool (at it's current state) is aimed to handle 90%+ of the cases, if we still have a handful of files that needs to be manually updated I think it's still a win

Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!

I concur, this tool (including its current state) it is totally a progress win! This was just nitpicking 🙊 about how to approach the future ~10% edge-cases.

This is not a show stopper.

🧹 In the future it would be helpful to have logger.debug() output with before-after (plus some context lines) of the altered code. But assuming the list mutations are safe... that would be out-of-scope for a POC of-course.

@coderabbitai, please analysis this function (e.g., around lines 172-197) looking for possible improvements that could ensure any worries about list modifications here are mitigated.

#!/bin/bash
# Get the complete apply_conf function implementation
ast-grep --pattern $'def apply_conf($$$) -> str:
    $$$'

@reactive-firewall, I've analyzed the apply_conf function (lines 172-196) and identified several potential improvements to ensure list modification safety:

Current Implementation Analysis

The function currently:

1. Splits content into lines
2. Collects all patches into a list
3. Processes patches in reverse order by line number
4. Uses lines.insert(lineno, patch) to modify the list

Potential Safety Issues & Improvements

1. Input Validation

def apply_conf(contents: str, conf: dict) -> str:
    lines = contents.splitlines()
    tree = ast.parse(contents)
    
    patches = list(iter_patches(tree, conf))
    
    # Validate line numbers before processing
    max_line = len(lines)
    valid_patches = [
        (lineno, patch) for lineno, patch in patches 
        if 0 <= lineno <= max_line
    ]
    
    for lineno, patch in sorted(valid_patches, reverse=True):
        lines.insert(lineno, patch)
    
    return "\n".join(lines)

2. Handle Duplicate Line Numbers

# Group patches by line number to handle duplicates safely
from collections import defaultdict

patches_by_line = defaultdict(list)
for lineno, patch in patches:
    patches_by_line[lineno].append(patch)

# Process in reverse order, inserting multiple patches at same line
for lineno in sorted(patches_by_line.keys(), reverse=True):
    for patch in reversed(patches_by_line[lineno]):  # Maintain order
        if 0 <= lineno <= len(lines):
            lines.insert(lineno, patch)

3. Immutable Approach (Safer)

def apply_conf(contents: str, conf: dict) -> str:
    original_lines = contents.splitlines()
    tree = ast.parse(contents)
    
    patches = list(iter_patches(tree, conf))
    
    # Build insertion map
    insertions = defaultdict(list)
    for lineno, patch in patches:
        if 0 <= lineno <= len(original_lines):
            insertions[lineno].append(patch)
    
    # Build new lines list without mutating original
    result_lines = []
    for i, line in enumerate(original_lines):
        # Insert patches before current line
        result_lines.extend(insertions.get(i, []))
        result_lines.append(line)
    
    # Handle patches at end of file
    result_lines.extend(insertions.get(len(original_lines), []))
    
    return "\n".join(result_lines)

4. With Debug Logging (As You Suggested)

import logging

def apply_conf(contents: str, conf: dict) -> str:
    logger = logging.getLogger(__name__)
    
    lines = contents.splitlines()
    tree = ast.parse(contents)
    
    patches = list(iter_patches(tree, conf))
    logger.debug(f"Applying {len(patches)} patches")
    
    for lineno, patch in sorted(patches, reverse=True):
        if 0 <= lineno <= len(lines):
            # Log before/after context
            start_ctx = max(0, lineno - 2)
            end_ctx = min(len(lines), lineno + 3)
            
            logger.debug(f"Before patch at line {lineno}:")
            for i in range(start_ctx, end_ctx):
                marker = " > " if i == lineno else "   "
                logger.debug(f"{marker}{i:3d}: {lines[i] if i < len(lines) else '<EOF>'}")
            
            lines.insert(lineno, patch)
            
            logger.debug(f"After patch:")
            for i in range(start_ctx, min(len(lines), end_ctx + 1)):
                marker = " + " if i == lineno else "   "
                logger.debug(f"{marker}{i:3d}: {lines[i]}")
    
    return "\n".join(lines)

Recommendation

For the POC, the current implementation is reasonably safe, but I'd recommend option 3 (immutable approach) as it eliminates list mutation concerns entirely while being easy to understand and debug. The logging enhancement you mentioned would be valuable for troubleshooting patch applications.

Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-19T03:16:56.511Z
Learning: Applies to Lib/test/**/*.py : When tests fail due to unsupported syntax, keep the test as `unittest.expectedFailure`, document that it requires PEP 695 support, and focus on tests that can be fixed through Rust code changes only

@ShaharNaveh, Overall LGTM! With the caveat, that as a POC, it has lots of potential for improvements.

Most of my inline comments are off-the-cuff, I recognize this is a proof-of-concept and I like the concept, so feel-free to dismiss any comments that are off-topic without response.