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.