💡 Verification agent

Critical: Disconnect between internal initializing field and Python-level __spec__._initializing attribute.

The refactored import logic looks correct, but there's a fundamental issue: this code checks __spec__._initializing (line 1389 via is_module_initializing), but the import_code_obj function in import.rs only sets the internal PyModule.initializing field. There's no code that exposes this internal state to Python as __spec__._initializing.

Without this connection, the circular import detection won't work as intended.

Consider either:

1. Setting __spec__._initializing in import_code_obj when setting the internal field
2. Modifying is_module_initializing to check the internal PyModule.initializing field instead

Run the following script to verify if __spec__._initializing is set anywhere in the codebase:

🏁 Script executed:

#!/bin/bash
# Search for any code that sets _initializing on spec objects
rg -A 5 "_initializing.*=" 

# Search for any references to the initializing field on PyModule
ast-grep --pattern 'initializing'

Length of output: 62

🏁 Script executed:

#!/bin/bash
set -e

# Search for any occurrences of the internal `initializing` field in Rust code
rg -n "initializing" -t rs

# Search for any usage of `__spec__` or `_initializing` on spec objects
rg -n "__spec__" -t rs
rg -n "_initializing" -t rs

Length of output: 62

🏁 Script executed:

#!/bin/bash
set -e

# Search for occurrences of 'initializing' in all Rust source files
rg -n "initializing" --glob '*.rs'

# Search for any usage of '__spec__' in Rust source
rg -n "__spec__" --glob '*.rs'

# Search for any explicit '_initializing' assignments or checks in Rust source
rg -n "_initializing" --glob '*.rs'

Length of output: 1656

Critical: Circular‐import detection is broken—spec._initializing is never set

The new is_module_initializing path in vm/src/frame.rs (lines 1389, 2405–2415) checks the Python‐level __spec__._initializing flag, but no code ever assigns _initializing on the module’s __spec__. We only toggle the internal PyModule.initializing field in vm/src/import.rs (lines 168, 172), so the “partially initialized module” branch will never fire.

To resolve this, choose one of the following fixes:

• In vm/src/import.rs (around lines 168–172), after calling

module.initializing.store(true/false, Ordering::Relaxed);

also set the Python‐level flag:

let spec = module.get_attr(&vm.ctx.new_str("__spec__"), vm)?;
spec.set_attr(&vm.ctx.new_str("_initializing"), vm.ctx.new_bool(true), vm)?;

(and similarly for false)

• Or in vm/src/frame.rs’s is_module_initializing (lines 2405–2415), downcast module to PyModule and read its internal initializing flag directly instead of querying __spec__.

Add appropriate tests to verify circular‐import error messages now appear.

In vm/src/frame.rs lines 1363 to 1408, the circular-import detection relies on
the Python-level __spec__._initializing flag, but this flag is never set,
causing the detection to fail. To fix this, either update vm/src/import.rs
around lines 168-172 to set the _initializing attribute on the module's __spec__
object whenever the internal PyModule.initializing flag is changed, or modify
the is_module_initializing function in vm/src/frame.rs (lines 2405-2415) to
downcast the module to PyModule and check the internal initializing field
directly. Additionally, add tests to confirm that circular-import errors are
correctly detected and reported.

💡 Verification agent

Helper function implementation is sound but relies on unset attribute.

The is_module_initializing function has proper error handling, but it checks for __spec__._initializing which isn't being set by the import system. This function needs to either:

1. Check the internal PyModule.initializing field if the module is a PyModule instance
2. Ensure that __spec__._initializing is properly set during import

Consider checking the internal field directly:

fn is_module_initializing(module: &PyObject, vm: &VirtualMachine) -> bool {
+    // First try to check the internal field if this is a PyModule
+    if let Ok(py_module) = module.downcast_ref::<PyModule>() {
+        use std::sync::atomic::Ordering;
+        return py_module.initializing.load(Ordering::Relaxed);
+    }
+    
+    // Fallback to checking __spec__._initializing
    let Ok(spec) = module.get_attr(&vm.ctx.new_str("__spec__"), vm) else {
        return false;
    };
    if vm.is_none(&spec) {
        return false;
    }
    let Ok(initializing_attr) = spec.get_attr(&vm.ctx.new_str("_initializing"), vm) else {
        return false;
    };
    initializing_attr.try_to_bool(vm).unwrap_or(false)
}

Run the following script to check how CPython handles module initialization tracking:

🌐 Web query:

How does CPython track module initialization state for circular import detection? Does it use __spec__._initializing?

💡 Result:

CPython tracks module initialization state for circular import detection by leveraging the sys.modules cache. When a module is first imported, a module object is placed into sys.modules immediately—before its code is executed. This ensures that if the module is imported again (such as via a circular import), Python will return this already-existing (but possibly only partially initialized) module object, rather than starting a new import. This mechanism is essential for breaking import cycles and preventing infinite recursion during import[3][7].

The __spec__._initializing attribute (or similar such as __spec__._initialized) is an internal implementation detail and is not the primary mechanism for detection of circular imports in CPython. There have been discussions and experimental ideas about using such an attribute to mark a module’s initialization state for more fine-grained control or for advanced import hacks like async imports[6][8]. However, in normal CPython operation and as of current mainstream Python versions, this attribute is either not present or not used by the import machinery for circular import detection.

Instead, here is how it works:

• When a module is being imported, it is immediately inserted into sys.modules, signaling "import in progress."
• If another module tries to import it during this time, it receives a reference to this partially initialized module[3][7].
• If the code tries to access names that haven’t been defined yet (because initialization hasn't finished), you get errors like:

  ImportError: cannot import name 'X' from 'Y' (most likely due to a circular import)[7]

• There is no robust, public-facing per-module "initializing" flag used by the import system; the presence of the module object in sys.modules before its code has finished running is the primary state signal.

Summary Table

In conclusion:
CPython does not use __spec__._initializing to track module initialization state for the purpose of circular import detection; it relies on the presence of the module in sys.modules during import.[3][7]

Citations:

• 1: https://github.com/bndr/pycycle
• 2: https://github.com/python/cpython/blob/master/Lib/test/test_import/__init__.py
• 3: https://rollbar.com/blog/how-to-fix-circular-import-in-python/
• 4: https://realpython.com/python-import/
• 5: https://www.geeksforgeeks.org/python/python-circular-imports/
• 6: https://discuss.python.org/t/async-imports-to-reduce-startup-times/69732
• 7: https://www.datacamp.com/tutorial/python-circular-import
• 8: Improve AttributeError message for partially initialized module python/cpython#77418
• 9: https://labex.io/tutorials/python-how-to-resolve-circular-imports-in-python-418812
• 10: https://docs.kanaries.net/topics/Python/python-circular-import

Streamline is_module_initializing to use internal flag and drop __spec__._initializing fallback.

• File: vm/src/frame.rs (lines 2405–2416)
• CPython doesn’t use __spec__._initializing for import tracking—modules in sys.modules signal “in progress.”
• RustPython’s PyModule already has an initializing flag; use that and return false for all other objects.

 fn is_module_initializing(module: &PyObject, vm: &VirtualMachine) -> bool {
-    // Fallback to checking __spec__._initializing
-    let Ok(spec) = module.get_attr(&vm.ctx.new_str("__spec__"), vm) else {
-        return false;
-    };
-    if vm.is_none(&spec) {
-        return false;
-    }
-    let Ok(initializing_attr) = spec.get_attr(&vm.ctx.new_str("_initializing"), vm) else {
-        return false;
-    };
-    initializing_attr.try_to_bool(vm).unwrap_or(false)
+    // Use internal initializing flag on PyModule
+    if let Ok(py_module) = module.downcast_ref::<PyModule>() {
+        use std::sync::atomic::Ordering;
+        return py_module.initializing.load(Ordering::Relaxed);
+    }
+    false
 }

In vm/src/frame.rs around lines 2405 to 2416, refactor the
is_module_initializing function to remove the fallback logic that checks
__spec__._initializing. Instead, check if the given module is a PyModule and
directly return its initializing flag. For all other object types, return false.
This aligns with CPython's approach and simplifies the function by relying on
the internal initializing flag of PyModule.