crates/vm/src/class.rs (1)

67-79: ITEMSIZE constant and slots.itemsize wiring look correct; clarify who owns it

Plumbing PyClassDef::ITEMSIZE into PyClassImpl::make_slots() is sane and keeps the default at 0 for existing types, while allowing manual impls to opt into a non‑zero tp_itemsize. At the same time, the derive macro now also sets slots.itemsize inside __extend_slots based on a #[pyclass(itemsize = ...)] on impl blocks.

That gives you two ways to set itemsize (the const and the impl attribute). Today the builtins (int/bytes/tuple) appear to rely only on the impl‑attribute path, leaving ITEMSIZE at its default. If that’s the intended split—ITEMSIZE for hand‑written classes, attribute for macro‑driven ones—it might be worth documenting to avoid future divergence between the two.

Also applies to: 209-225

crates/derive-impl/src/pyclass.rs (1)

162-207: itemsize pyimpl attribute is plumbed correctly into generated __extend_slots

The new flow—parsing itemsize = <expr> into ExtractedImplAttrs and emitting:

fn __extend_slots(slots: &mut ::rustpython_vm::types::PyTypeSlots) {
    slots.itemsize = <expr>;
    // existing slot extensions…
}

for the main impl works well for cases like #[pyclass(itemsize = 4)] impl PyInt { .. } and #[pyclass(itemsize = std::mem::size_of::<crate::PyObjectRef>())] impl PyTuple { .. }. Because this runs before trait extend_slots calls, trait-provided slots see the final itemsize.

Two minor edge cases worth noting:

• itemsize used on a trait-level #[pyclass] impl is currently parsed but ignored, which is a bit non-obvious.
• Multiple #[pyclass] impls for the same payload type could each specify itemsize, with the last one silently “winning”.

Neither is incorrect, but if you want clearer invariants you might later tighten this by rejecting itemsize on traits and/or detecting conflicting itemsize values across impls.

Also applies to: 1624-1650, 1735-1758

crates/vm/src/builtins/type.rs (2)

951-954: New __itemsize__ getter cleanly exposes the slot field

Exposing self.slots.itemsize via __itemsize__ is the right surface for Python-side introspection and lines up with how __basicsize__ is already handled. The implementation is trivial and side‑effect free; if you later want full CPython parity for subclasses, you may also want to consider whether heap types created via type() should inherit their base’s itemsize for introspection, not just for layout checks.

---

1355-1511: __slots__ / itemsize handling and solid_base layout checks look correct; a couple of edge cases to double‑check

The new type.__new__ path around __slots__ and itemsize is a substantial improvement:

• Rejecting bytes as __slots__ or as individual slot items, and requiring identifiers via isidentifier(), matches Python’s expectations.
• Treating any non‑"__dict__" / "__weakref__" entry as “custom” and forbidding such custom slots when base.slots.itemsize > 0 gives you the intended “nonempty slots not supported for subtype of ''” behavior for variable-sized bases like int, bytes, and tuple.
• Tracking duplicates for __dict__ / __weakref__, preventing redefinition when the base already supplies them, and rejecting slot names that conflict with class attributes are all aligned with CPython’s rules.
• Filtering "__dict__" out of the stored slot tuple while still setting HAS_DICT | MANAGED_DICT and then adding a __dict__ descriptor only when needed produces the right combination of layout and attribute behavior.
• The updated solid_base using (basicsize, itemsize) to detect extra_ivars is more faithful to CPython’s layout checks and keeps best_base’s instance‑layout conflict detection consistent with the new itemsize plumbing.

Two subtleties worth verifying with tests:

1. Weakref inheritance check – for built‑in bases, base_has_weakref is approximated as base.attributes.read().contains_key("__weakref__"). CPython looks up __weakref__ across the MRO, so a built‑in that only inherits the descriptor (rather than defining it in its own dict) might slip through here and allow an extra "__weakref__" slot. A quick CPython vs RustPython test around:

   class C(<some builtin with weakref support>):
       __slots__ = ("__weakref__",)

   would confirm whether behavior matches.

2. Subclass __itemsize__ introspection – heap types created via type() currently start with itemsize == 0 even if their solid base has a non‑zero itemsize. That’s fine for layout/slots checks (you already consult the base’s itemsize), but their __itemsize__ values may not mirror CPython’s for subclasses of int/bytes/tuple if CPython exposes the base’s tp_itemsize there.

Functionally this all looks sound; the above points are mainly about nailing CPython compatibility in corner cases.

Also applies to: 1525-1564, 2175-2185

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

Learnt from: CR
Repo: RustPython/RustPython PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-27T14:03:49.011Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust

Learnt from: youknowone
Repo: RustPython/RustPython PR: 6110
File: vm/src/frame.rs:1311-1316
Timestamp: 2025-08-26T05:20:54.540Z
Learning: In RustPython's pattern matching implementation, only certain builtin types should have the SEQUENCE flag: list and tuple are confirmed sequences. The user youknowone indicated that bytes, bytearray are not considered sequences in this context, even though they implement sequence-like protocols.

Learnt from: youknowone
Repo: RustPython/RustPython PR: 6110
File: vm/src/frame.rs:1311-1316
Timestamp: 2025-08-26T05:20:54.540Z
Learning: In the RustPython codebase, only certain builtin types should be marked with the SEQUENCE flag for pattern matching. List and tuple are sequences, but bytes, bytearray, and range are not considered sequences in this context, even though they may implement sequence-like protocols.

Learnt from: CR
Repo: RustPython/RustPython PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-27T14:03:49.011Z
Learning: Applies to **/*.rs : Use the macro system (`pyclass`, `pymodule`, `pyfunction`, etc.) when implementing Python functionality in Rust