Preface

Recently, while attempting to automate the process of updating Python standard libraries in RustPython, I became exhausted from various challenges and stopped working on it. However, I suddenly wanted to preserve these ideas, so I'm writing this post.
The problems and ideas I considered might not actually be very helpful, so it's fine if they're just treated as "Issue A" and moved on.
Since I wrote this in my native Korean before having it translated, there may be some mistranslations, but I ask for your understanding.

Problems

Regarding Python standard library updates, I see two main issues. One is that updating them requires significant labor, and the other is that it's difficult to easily determine which Python version each file is based on.

From a labor perspective

I'm not sure how others work, but in my case, I would copy files from the CPython repository to the same path in the RustPython repository, then use diff commands to try preserving existing comments.
Manually adding decorators like @unittest.expectedFailure was quite labor-intensive.

As a solution, I considered automated scripts running on GitHub Actions. I thought about implementing it with the following structure, but couldn't proceed due to difficulties in setting up different OS hosts and personal exhaustion:

1. Copy desired modules or files from the CPython repository.
2. Run the following process in Windows, macOS, and Linux environments to collect reports:
   1. Use cargo run -- -m test --list-cases <test> to get all potentially executable test cases.
   2. Run each test case in a separate process with cargo run -- -m unittest <test>, as some cases might cause panics or deadlocks.
   3. Collect test success/failure/panic status and create a JSON report to upload to a separate repository (e.g., S3).
3. Use LibCST to parse test files and build an inheritance graph between test classes.
4. Organize failing or panicking test cases from reports and create an execution plan, considering whether to add decorators to parent classes or create arbitrary methods in child classes that call parent methods.
5. Apply changes using LibCST according to the execution plan and submit a PR.
6. Have humans review and finally merge it.

This approach somewhat ignores:

• Existing comments are disregarded. For example, failure reasons appended to TODO: RUSTPYTHON comments aren't preserved. They could be preserved, but I couldn't establish criteria for which comments to keep.

While agents like Claude Code can handle most cases well, making such automation somewhat less meaningful, I still believe automating what can be automated is good.
If this idea seems reasonable and there are edge cases I haven't considered, please add comments with additional opinions.

About standard library version management

This idea actually came up while writing the automation script.
Currently, the RustPython project takes standard library files from CPython, arbitrarily adds decorators like @unittest.expectedFailure to pass tests, then gradually improves them.
However, since we modify the original standard library files, it's hard to immediately tell which version they're based on when comparing with CPython standard library files (though you can check commit logs), and we need to use libraries like LibCST for somewhat complex modifications.

This idea aims to use original files unchanged to make updates easier and simplify version identification (e.g., whether it's a CPython a.b version file).

Unlike the previous idea, I don't have concrete implementation details, but the concept would be:

• Create a custom test runner inheriting from unittest test runner and use it as the main runner. This runner would receive lists of which test cases fail or should be skipped.
• The test list would be an array like <testcase>: FAILURE | SKIP. Based on values, it would skip or run expecting failure. Managed per OS (e.g., testhints/linux-arm64.json).

However, the current approach of adding decorators and comments allows searching for TODO: RUSTPYTHON to find work targets while viewing test source code, so changing to this new idea might lose this advantage.
Also, since I've never actually attempted to implement this idea, it might be somewhat flawed.