GeezerVison

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

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