💡 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.