benches/README.md (1)

10-16: Extend example to include list.sort() microbench and show exact-match usage

Once you add the in-place list.sort() microbenchmark, surface it here. Also consider an exact-match example to avoid unintentionally matching other benchmarks.

Apply:

 ```shell
-cargo bench sort
+cargo bench sort
+# Or, for the in-place list.sort() microbenchmark:
+cargo bench list_sort
+# For an exact match on just "sort":
+cargo bench '^sort$'

</blockquote></details>

</blockquote></details>

<details>
<summary>📜 Review details</summary>

**Configuration used: .coderabbit.yml**
**Review profile: CHILL**
**Plan: Pro**


<details>
<summary>📥 Commits</summary>

Reviewing files that changed from the base of the PR and between a9a9e3bf118f6c631ef99fe7174215254f846097 and d96712bd950005d8d813bd3a4d8f44fb0426ec58.

</details>

<details>
<summary>📒 Files selected for processing (2)</summary>

* `benches/README.md` (1 hunks)
* `benches/microbenchmarks/sort.py` (1 hunks)

</details>

<details>
<summary>🧰 Additional context used</summary>

<details>
<summary>📓 Path-based instructions (1)</summary>

<details>
<summary>**/*.py</summary>


**📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)**

> `**/*.py`: Follow PEP 8 style for custom Python code
> Use ruff for linting Python code

Files:
- `benches/microbenchmarks/sort.py`

</details>

</details><details>
<summary>🧠 Learnings (1)</summary>

<details>
<summary>📚 Learning: 2025-07-19T03:16:56.511Z</summary>

Learnt from: CR
PR: RustPython/RustPython#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-19T03:16:56.511Z
Learning: Generate documentation with cargo doc --no-deps --all

**Applied to files:**
- `benches/README.md`

</details>

</details><details>
<summary>🧬 Code Graph Analysis (1)</summary>

<details>
<summary>benches/microbenchmarks/sort.py (2)</summary><blockquote>

<details>
<summary>stdlib/src/random.rs (1)</summary>

* `random` (42-45)

</details>
<details>
<summary>vm/src/stdlib/builtins.rs (1)</summary>

* `sorted` (815-820)

</details>

</blockquote></details>

</details><details>
<summary>🪛 Flake8 (7.2.0)</summary>

<details>
<summary>benches/microbenchmarks/sort.py</summary>

[error] 3-3: undefined name 'ITERATIONS'

(F821)

</details>

</details>

</details>

<details>
<summary>⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)</summary>

* GitHub Check: Run snippets and cpython tests (macos-latest)
* GitHub Check: Run snippets and cpython tests on wasm-wasi
* GitHub Check: Run snippets and cpython tests (windows-latest)
* GitHub Check: Run snippets and cpython tests (ubuntu-latest)
* GitHub Check: Run tests under miri
* GitHub Check: Check the WASM package and demo
* GitHub Check: Check Rust code with rustfmt and clippy
* GitHub Check: Run rust tests (ubuntu-latest)
* GitHub Check: Run rust tests (windows-latest)
* GitHub Check: Run rust tests (macos-latest)
* GitHub Check: Ensure compilation on various targets

</details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->

benches/microbenchmarks/sort.py (1)

1-1: Ensure Consistent RNG Seeding Across Microbenchmarks

No other benchmarks in benches/microbenchmarks/ currently seed the RNG. If you’d like deterministic inputs for easier cross-run comparisons, consider adding a fixed seed at the top of benches/microbenchmarks/sort.py:

-from random import random
+from random import random, seed
+seed(0)

This change will align sort.py with a reproducible input setup—apply only if it matches the rest of your benchmarking strategy.

Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro

Learnt from: jackoconnordev
PR: RustPython/RustPython#6086
File: benches/microbenchmarks/sort.py:7-7
Timestamp: 2025-08-09T22:55:10.479Z
Learning: In RustPython benchmarks, when testing sorting performance, benchmarking only `sorted()` is sufficient since it internally uses the same sorting logic as `list.sort()`. The only difference is that `sorted()` creates a copy first, so testing both would be redundant for evaluating the sorting algorithm's performance.

Learnt from: jackoconnordev
PR: RustPython/RustPython#6086
File: benches/microbenchmarks/sort.py:7-7
Timestamp: 2025-08-09T22:55:10.479Z
Learning: In RustPython benchmarks, when testing sorting performance, benchmarking only `sorted()` is sufficient since it internally uses the same sorting logic as `list.sort()`. The only difference is that `sorted()` creates a copy first, so testing both would be redundant for evaluating the sorting algorithm's performance.

Learnt from: jackoconnordev
PR: RustPython/RustPython#6086
File: benches/microbenchmarks/sort.py:1-3
Timestamp: 2025-08-09T22:56:24.504Z
Learning: In RustPython's microbenchmarks (benches/microbenchmarks/*.py), the variable `ITERATIONS` is intentionally used without being defined in the Python files. It is injected by the cargo bench harness at runtime. This pattern should be maintained for consistency across all microbenchmarks, and F821 lint warnings for undefined `ITERATIONS` are expected and acceptable in this context.

benches/microbenchmarks/sort.py (2)

4-4: ITERATIONS is intentionally harness-injected; F821 can be ignored here

Per the microbench pattern in this repo, ITERATIONS is provided by the harness. Keeping it undefined in the file is consistent and expected.

---

8-8: In-place sort mutates the input; subsequent timed invocations will sort an already-sorted list

Because setup runs once and only the section after “# ---” is timed repeatedly, mutating unsorted_list will cause later iterations to measure best-case sorting of an already-sorted list, skewing results. Prefer a non-mutating call or copy within the timed section.

Apply one of the following:

Option A (preferred, aligns with “benchmark only sorted()” learning):

-unsorted_list.sort()
+sorted(unsorted_list)

Option B (if you explicitly want to time list.sort()):

-unsorted_list.sort()
+unsorted_list.copy().sort()

benches/README.md (1)

17-17: Nit: small wording/style improvement and consistency for shell blocks

• Prefer “benchmark with” over “bench against” for clarity.
• Keep shell blocks consistent: either include a $ prompt in both code blocks or neither (the earlier “cargo bench sort” block has no $ ).

Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro

Learnt from: jackoconnordev
PR: RustPython/RustPython#6086
File: benches/microbenchmarks/sort.py:7-7
Timestamp: 2025-08-09T22:55:10.512Z
Learning: In RustPython benchmarks, when testing sorting performance, benchmarking only `sorted()` is sufficient since it internally uses the same sorting logic as `list.sort()`. The only difference is that `sorted()` creates a copy first, so testing both would be redundant for evaluating the sorting algorithm's performance.

Learnt from: jackoconnordev
PR: RustPython/RustPython#6086
File: benches/microbenchmarks/sort.py:7-7
Timestamp: 2025-08-09T22:55:10.512Z
Learning: In RustPython benchmarks, when testing sorting performance, benchmarking only `sorted()` is sufficient since it internally uses the same sorting logic as `list.sort()`. The only difference is that `sorted()` creates a copy first, so testing both would be redundant for evaluating the sorting algorithm's performance.

Learnt from: jackoconnordev
PR: RustPython/RustPython#6086
File: benches/microbenchmarks/sort.py:1-3
Timestamp: 2025-08-09T22:56:24.527Z
Learning: In RustPython's microbenchmarks (benches/microbenchmarks/*.py), the variable `ITERATIONS` is intentionally used without being defined in the Python files. It is injected by the cargo bench harness at runtime. This pattern should be maintained for consistency across all microbenchmarks, and F821 lint warnings for undefined `ITERATIONS` are expected and acceptable in this context.

benches/microbenchmarks/sort.py (1)

4-4: F821 (undefined name ‘ITERATIONS’) is intentional per harness injection

Per prior discussion and existing microbench patterns, ITERATIONS is injected by the harness; no inline default or noqa is required here.

benches/README.md (2)

13-15: Fix markdownlint MD014: remove leading $ in shell blocks

Use plain commands in fenced blocks to satisfy MD014 and improve copy/paste UX.

 ```shell
-$ cargo bench sort
+cargo bench sort

---

`17-22`: **Minor grammar + markdownlint MD014 cleanups**

- Prefer “benchmark against” over “bench against”.
- Remove leading “$” in shell example for MD014.


```diff
-To view Python tracebacks during benchmarks, run `RUST_BACKTRACE=1 cargo bench`. You can also bench against a
+To view Python tracebacks during benchmarks, run `RUST_BACKTRACE=1 cargo bench`. You can also benchmark against a

 ```shell
-$ PYTHON_SYS_EXECUTABLE=python3.13 cargo bench
+PYTHON_SYS_EXECUTABLE=python3.13 cargo bench

</blockquote></details>
<details>
<summary>benches/microbenchmarks/sort.py (1)</summary><blockquote>

`1-4`: **Avoid mutating global RNG state: use a local Random(0) instance**

Seeding the global RNG can affect other benchmarks if they share a process. A local RNG preserves reproducibility without global side effects.


```diff
-from random import random, seed
-seed(0)
+from random import Random
+rng = Random(0)
 
-unsorted_list = [random() for _ in range(5 * ITERATIONS)]
+unsorted_list = [rng.random() for _ in range(5 * ITERATIONS)]

Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro

Learnt from: jackoconnordev
PR: RustPython/RustPython#6086
File: benches/microbenchmarks/sort.py:7-7
Timestamp: 2025-08-09T22:55:10.512Z
Learning: In RustPython benchmarks, when testing sorting performance, benchmarking only `sorted()` is sufficient since it internally uses the same sorting logic as `list.sort()`. The only difference is that `sorted()` creates a copy first, so testing both would be redundant for evaluating the sorting algorithm's performance.

Learnt from: jackoconnordev
PR: RustPython/RustPython#6086
File: benches/microbenchmarks/sort.py:7-7
Timestamp: 2025-08-09T22:55:10.512Z
Learning: In RustPython benchmarks, when testing sorting performance, benchmarking only `sorted()` is sufficient since it internally uses the same sorting logic as `list.sort()`. The only difference is that `sorted()` creates a copy first, so testing both would be redundant for evaluating the sorting algorithm's performance.

Learnt from: jackoconnordev
PR: RustPython/RustPython#6086
File: benches/microbenchmarks/sort.py:1-3
Timestamp: 2025-08-09T22:56:24.527Z
Learning: In RustPython's microbenchmarks (benches/microbenchmarks/*.py), the variable `ITERATIONS` is intentionally used without being defined in the Python files. It is injected by the cargo bench harness at runtime. This pattern should be maintained for consistency across all microbenchmarks, and F821 lint warnings for undefined `ITERATIONS` are expected and acceptable in this context.

benches/README.md (3)

10-16: Clarify filter name and fix markdownlint MD014 ($ prompt) in command example.

• "sort microbenchmark" vs file name "sorted.py" can confuse readers. Using the exact name avoids accidental matches with other benches.
• Remove leading "$" to satisfy MD014.

Apply this diff:

-`cargo bench` supports name matching to run a subset of the benchmarks. To
-run only the sort microbenchmark, you can run:
+`cargo bench` supports name matching to run a subset of the benchmarks. To
+run only the sorted microbenchmark, run:
 
 ```shell
-$ cargo bench sort
+cargo bench sorted

---

`17-22`: **Prefer “benchmark” over “bench” and fix MD014 ($ prompt) in the Python example.**

- Minor wording polish.
- Remove leading "$" for markdownlint.


Apply this diff:

```diff
-To view Python tracebacks during benchmarks, run `RUST_BACKTRACE=1 cargo bench`. You can also bench against a
+To view Python tracebacks during benchmarks, run `RUST_BACKTRACE=1 cargo bench`. You can also benchmark against a
 specific installed Python version by running:
 
 ```shell
-$ PYTHON_SYS_EXECUTABLE=python3.13 cargo bench
+PYTHON_SYS_EXECUTABLE=/usr/bin/python3.13 cargo bench

---

`7-8`: **Fix small typo (“use use”).**

Minor duplication in the sentence.


Apply this diff:

```diff
-Running `cargo bench` from the root of the repository will start the benchmarks. Once done there will be a graphical 
-report under `target/criterion/report/index.html` that you can use use to view the results.
+Running `cargo bench` from the root of the repository will start the benchmarks. Once done there will be a graphical 
+report under `target/criterion/report/index.html` that you can use to view the results.

benches/microbenchmarks/sorted.py (1)

1-5: Avoid F821 (undefined name) and make the file runnable outside the harness.

ITERATIONS is provided by the harness at runtime, but static linters (ruff/flake8 F821) and manual runs will flag/break. Add a harmless fallback that the harness will override.

Apply this diff:

 from random import random, seed
 seed(0)
 
+# Fallback for linters/manual runs; the harness sets ITERATIONS before execution.
+if "ITERATIONS" not in globals():
+    ITERATIONS = 1000
+
 unsorted_list = [random() for _ in range(5 * ITERATIONS)]

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: jackoconnordev
PR: RustPython/RustPython#6086
File: benches/microbenchmarks/sort.py:7-7
Timestamp: 2025-08-09T22:55:10.512Z
Learning: In RustPython benchmarks, when testing sorting performance, benchmarking only `sorted()` is sufficient since it internally uses the same sorting logic as `list.sort()`. The only difference is that `sorted()` creates a copy first, so testing both would be redundant for evaluating the sorting algorithm's performance.

Learnt from: jackoconnordev
PR: RustPython/RustPython#6086
File: benches/microbenchmarks/sort.py:7-7
Timestamp: 2025-08-09T22:55:10.512Z
Learning: In RustPython benchmarks, when testing sorting performance, benchmarking only `sorted()` is sufficient since it internally uses the same sorting logic as `list.sort()`. The only difference is that `sorted()` creates a copy first, so testing both would be redundant for evaluating the sorting algorithm's performance.

benches/README.md (6)

7-8: Fix typo and readability in benchmark report sentence.

Remove the duplicated word and add a comma for flow.

-Running `cargo bench` from the root of the repository will start the benchmarks. Once done there will be a graphical
-report under `target/criterion/report/index.html` that you can use use to view the results.
+Running `cargo bench` from the root of the repository will start the benchmarks. Once done, there will be a graphical
+report under `target/criterion/report/index.html` that you can use to view the results.

---

10-15: Clarify how name matching works.

Note that the filter is substring-based and may match multiple benchmarks.

-`cargo bench` supports name matching to run a subset of the benchmarks. To
-run only the sorted microbenchmark, you can run:
+`cargo bench` supports substring-based name matching to run a subset of the benchmarks. To
+run only the sorted microbenchmark, you can run (this may also match other names containing "sorted"):

---

17-22: Make Python version example resilient across environments.

Keep 3.13, but note that any installed version is acceptable.

-To view Python tracebacks during benchmarks, run `RUST_BACKTRACE=1 cargo bench`. You can also bench against a
-specific installed Python version by running:
+To view Python tracebacks during benchmarks, run `RUST_BACKTRACE=1 cargo bench`. You can also bench against a
+specific installed Python version by running (adjust to your local version if different):

---

26-27: Disambiguate benchmark directory path.

Readers at repo root may misread this as a top-level path.

-Simply adding a file to the `benchmarks/` directory will add it to the set of files benchmarked. Each file is tested
+Simply adding a file to the `benches/benchmarks/` directory will add it to the set of files benchmarked. Each file is tested

---

34-36: Standardize terminology: “microbenchmark” (closed form).

Use a single, consistent term.

-Micro benchmarks are small snippets of code added under the `microbenchmarks/` directory. A microbenchmark file has
+Microbenchmarks are small snippets of code added under the `microbenchmarks/` directory. A microbenchmark file has

Also consider updating the section header on Line 32 to “Adding a microbenchmark” for consistency.

---

60-60: Use Apple’s casing: “macOS”.

-## MacOS setup
+## macOS setup

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: jackoconnordev
PR: RustPython/RustPython#6086
File: benches/microbenchmarks/sort.py:7-7
Timestamp: 2025-08-09T22:55:10.512Z
Learning: In RustPython benchmarks, when testing sorting performance, benchmarking only `sorted()` is sufficient since it internally uses the same sorting logic as `list.sort()`. The only difference is that `sorted()` creates a copy first, so testing both would be redundant for evaluating the sorting algorithm's performance.

Learnt from: jackoconnordev
PR: RustPython/RustPython#6086
File: benches/microbenchmarks/sort.py:1-3
Timestamp: 2025-08-09T22:56:24.527Z
Learning: In RustPython's microbenchmarks (benches/microbenchmarks/*.py), the variable `ITERATIONS` is intentionally used without being defined in the Python files. It is injected by the cargo bench harness at runtime. This pattern should be maintained for consistency across all microbenchmarks, and F821 lint warnings for undefined `ITERATIONS` are expected and acceptable in this context.