Actionable comments posted: 2

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@crates/capi/src/methodobject.rs`:
- Around line 91-114: The VARARGS/VARARGS|KEYWORDS/FASTCALL/FASTCALL|KEYWORDS
branches always call take_self_arg which strips the first positional arg even
when has_self is false; fix by capturing the local has_self (the same way NOARGS
and O do) and either (A) pass has_self into take_self_arg so the adapters
(call_function, call_fast_function, call_function_with_keywords,
call_fast_function_with_keywords) can honor it, or (B) branch each case on
has_self and create different callable signatures (one that calls take_self_arg
when has_self==true and one that forwards args untouched when false) before
calling vm.ctx.new_method_def with the appropriate callable.
- Around line 78-90: The NOARGS branch (PyMethodFlags::NOARGS) incorrectly
creates and passes an empty tuple for args when has_self is true; change the
closure created in that branch (the callable that takes zelf: PyObjectRef) to
call call_function with None for the args parameter (i.e., pass None so it
becomes NULL) instead of Some(vec![zelf]) wrapped as an empty tuple, or
alternatively implement a small helper (e.g., call_function_noargs) that always
forwards NULL for the args parameter; update the callable and keep using
vm.ctx.new_method_def(name, callable, flags, doc) so behavior matches the
has_self=false path.

Nice groundwork on the C API surface. Build is clean and clippy passes the workspace lint set, which already includes pedantic and a fair bit of nursery. Most of what's left is semantic.

1. VARARGS / FASTCALL paths strip a real user argument as self when the function has no bound self.

PyMethodFlags::VARARGS => {
    let callable = move |args: PosArgs, vm: &VirtualMachine| unsafe {
        call_function(vm, method, flags, Some(args))
    };
    ...
},

fn take_self_arg(args: &mut FuncArgs, flags: PyMethodFlags) -> Option<PyObjectRef> {
    if flags.contains(PyMethodFlags::STATIC) { None } else { args.take_positional() }
}

Callable::call for PyNativeFunction only prepends zelf when zelf.is_some() && !STATIC. After PyCFunction_New(ml, NULL) with METH_VARARGS, calling fn(a, b) makes take_self_arg consume a as self and the C function sees args = (b,). Silent data corruption with no error. Same shape for the three other branches at lines 95 to 118. NOARGS and O already split on has_self; the VARARGS / FASTCALL family needs the same treatment, or pass has_self into take_self_arg.

2. module is silently dropped, so __module__ is always None for anything built through this API.

pub unsafe extern "C" fn PyCMethod_New(
    ml: *mut PyMethodDef,
    slf: *mut PyObject,
    _module: *mut PyObject,
    _cls: *mut PyTypeObject,
) -> *mut PyObject {

CPython does op->m_module = Py_XNewRef(module) and exposes it via __module__. Here it is bound to _module and never read. HeapMethodDef::build_function also lacks a module parameter, so even threading it through would not reach PyNativeFunction.module. Breaks inspect.getmodule, pickling and traceback module attribution.

3. assert! and .expect() across an extern \"C\" boundary.

with_vm(|vm| -> PyResult {
    assert!(
        _cls.is_null(),
        \"PyCMethod_New does not support METH_METHOD on abi3\"
    );

vm.take_raised_exception()
    .expect(\"Native function returned NULL, but there was no exception set\")

with_vm does not catch panics, and neither function is extern \"C-unwind\", so a panic here aborts the process. Any caller that passes a non-null cls (the PEP 573 path with METH_METHOD | METH_FASTCALL | METH_KEYWORDS) takes the interpreter down. Likewise for any buggy extension that returns NULL without PyErr_SetString. Both should be vm.new_system_error(...) plus a NULL return, matching _Py_CheckFunctionResult in CPython.

4. PyMethodFlags::from_bits rejects valid CPython flag combinations.

let flags = PyMethodFlags::from_bits(ml.ml_flags as u32)
    .ok_or_else(|| vm.new_system_error(\"PyMethodDef contains unknown flags\"))?;

METH_COEXIST (0x40) and METH_STACKLESS (0x100) are commented out of PyMethodFlags in crates/vm/src/function/method.rs. CPython masks unknown bits and treats them as ignored, so a textbook pattern like {\"__contains__\", impl, METH_O | METH_COEXIST, NULL} (used by several stdlib C modules) fails registration outright. Either switch to from_bits_truncate or declare the bits.

5. CStr::from_ptr(ml.ml_name) with no null check.

let name = unsafe { CStr::from_ptr(ml.ml_name) }
    .to_str()
    .map_err(|_| vm.new_system_error(\"Method name was not valid UTF-8\"))?;

Null ml_name is UB. ml_doc is already guarded with NonNull::new two lines down, so this is also an internal inconsistency. Same guard plus a SystemError.

Minor: the #[cfg(false)] mod tests block at lines 309 to 369 is dead code that references pyo3 types not declared as a dev dependency. Either wire it into CI or drop it.