src/shell.rs (1)

155-155: Consider whether logging raw REPL input is desirable

debug!("You entered {line:?}"); will emit every line the user types – including potentially sensitive data – to the log at debug level.
If the interactive shell can ever run in production or be embedded in another process that collects logs, this could leak secrets.

-debug!("You entered {line:?}");
+// Debug-level logging can expose user input verbatim; enable only when really useful.
+debug!(target: "repl", "You entered {line:?}");

Alternatively gate the statement behind a feature flag or redact long inputs.

vm/src/frame.rs (1)

1670-1670: Debug message looks good, just watch allocation cost

debug!("Exception raised: {exception:?} …") allocates the full Debug representation of the exception even when the debug level is disabled, because log still formats the message inside the macro.
If the exception objects can be large or contain heavy .repr() implementations, you might prefer:

if log::log_enabled!(log::Level::Debug) {
    debug!("Exception raised: {exception:?} with cause: {cause:?}");
}

Purely optional; current code is acceptable for most cases.

vm/src/stdlib/ctypes/base.rs (1)

254-254: Nit: minor wording tweak

The message now reads “Array length must be >= 0, not {n}”.
Consider adding a space after the comma for consistency with other errors:

-return Err(vm.new_value_error(format!("Array length must be >= 0, not {n}")));
+return Err(vm.new_value_error(format!("array length must be >= 0, not {n}")));

Also lower-case the first word to follow CPython style. Optional.

vm/src/vm/compile.rs (1)

52-52: OK, but think about back-pressure instead of process::exit

Logging improved; however, the block still terminates the whole VM on an IO error.
For library users this is surprising. Returning an Err upward would give callers control.

Out of scope for this PR, just flagging.

vm/src/stdlib/ctypes/function.rs (1)

80-86: Consider using CString to guard against interior NULs

format!("{function}\0") is concise, but it silently accepts function names that might already contain '\0', producing an over-long C string.
Wrapping the name in CString::new() would validate this upfront and avoid undefined behaviour when the symbol is looked up.

+use std::ffi::CString;
 ...
-        let terminated = format!("{function}\0");
-        let pointer: Symbol<'_, FP> = unsafe {
-            library
-                .get(terminated.as_bytes())
+        let terminated = CString::new(function)
+            .map_err(|_| vm.new_value_error("Function name contains NUL byte".to_owned()))?;
+        let pointer: Symbol<'_, FP> = unsafe {
+            library
+                .get(terminated.as_c_str().to_bytes_with_nul())
                 .map_err(|err| err.to_string())
                 .map_err(|err| vm.new_attribute_error(err))?
         };

Would you like a follow-up patch covering the additional use std::ffi::CString; import and the error mapping?

vm/src/builtins/object.rs (1)

55-62: Minor wording polish for the new error message

"class {name} without an implementation for abstract method …" reads a little awkwardly.
Consider adding a verb for clarity:

-return Err(vm.new_type_error(format!(
-    "class {name} without an implementation for abstract method '{methods}'"
-)));
+return Err(vm.new_type_error(format!(
+    "class {name} has no implementation for abstract method '{methods}'"
+)));

Same tweak applies to the plural branch below.

stdlib/src/csv.rs (1)

350-351: Redundant to_string() allocation

format! already returns a String; the extra .to_string() just clones the
buffer.

-return Err(vm.new_type_error(
-    format!("field_size_limit() takes at most 1 argument ({arg_len} given)")
-        .to_string(),
-));
+return Err(vm.new_type_error(format!(
+    "field_size_limit() takes at most 1 argument ({arg_len} given)"
+)));

This shaves an allocation and removes a clippy inherent_to_string warning.

vm/src/exceptions.rs (1)

208-210: Minor allocation nit: avoid an extra String

filename_suffix = format!(" ({filename})"); allocates a new String.
Because filename_suffix is only appended once, a cheaper option is:

-filename_suffix = format!(" ({filename})");
+filename_suffix.push_str(" (");
+filename_suffix.push_str(filename.as_str());
+filename_suffix.push(')');

Not critical, just a micro-optimisation.

vm/src/builtins/complex.rs (1)

65-72: Consider printing the type’s Python-level name

{ret_class} ends up using Display for Py<PyType>, which produces something like <class 'complex'>.
If you want the message to mirror CPython more closely and avoid the pointer-like wrapper you could use:

-format!(
-    "__complex__ returned non-complex (type {ret_class}).  \
+format!(
+    "__complex__ returned non-complex (type {}).  \
     The ability to return an instance of a strict subclass of complex \
     is deprecated, and may be removed in a future version of Python.",
-    ret_class.name(),   // <-- uses the type’s __name__
-)
+    ret_class.name(),
+)

Purely cosmetic; existing code compiles and behaves correctly.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro