[issue16392] import crashes on circular imports in ext modules

Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16392] import crashes on circular imports in ext modules

Brett Cannon added the comment: https://www.python.org/dev/peps/pep-0489/ is trying to come up with a redesign of extension module loading and no one has submitted a patch for the documentation (although Stefan has inlined proposed wording in a comment). --

[issue16392] import crashes on circular imports in ext modules

R. David Murray added the comment: Yes, the resolution of this issue will be to add documentation. Someone should turn Stefan's comment into a patch. -- assignee: - docs@python components: +Documentation nosy: +docs@python, r.david.murray stage: - needs patch versions: +Python 3.5

[issue16392] import crashes on circular imports in ext modules

Omer Katz added the comment: Is this issue resolved in any way? Has there been a decision made on how to resolve it? What's the status here? -- nosy: +Omer.Katz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16392

[issue16392] import crashes on circular imports in ext modules

Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16392 ___

[issue16392] import crashes on circular imports in ext modules

Changes by Andrew Svetlov andrew.svet...@gmail.com: -- nosy: +asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16392 ___ ___

[issue16392] import crashes on circular imports in ext modules

Changes by Eric Snow ericsnowcurren...@gmail.com: -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16392 ___ ___ Python-bugs-list

[issue16392] import crashes on circular imports in ext modules

Brett Cannon added the comment: The fully qualified name requirement is definitely a design flaw where init functions should just be given the module object with everything already set, just like what @importlib.util.module_for_loader does. Hopefully we can come up with a solution through

[issue16392] import crashes on circular imports in ext modules

Stefan Behnel added the comment: Agreed. Since it doesn't really fit into any specific function documentation, I would place it right at the top. Something like this: The following functions can be used by C code to call into Python's import machinery. Note that Python 3 does not

[issue16392] import crashes on circular imports in ext modules

Brett Cannon added the comment: I was thinking somewhere in http://docs.python.org/3/c-api/import.html since this only comes up when you try to execute an import during extension module initialization that involves a circular import. -- ___ Python

[issue16392] import crashes on circular imports in ext modules

Antoine Pitrou added the comment: Maybe we should add a warning in some documentation somewhere about this and then close the issue? I don't really know where to add it, in the C API docs perhaps, -- ___ Python tracker rep...@bugs.python.org

[issue16392] import crashes on circular imports in ext modules

Stefan Behnel added the comment: The problem is a) that the module does not necessarily know to which place it eventually gets installed (Cython relies on the distutils Extension not lying to it, for example, which people do from time to time), and b) that the call to Py_InitModule() only

[issue16392] import crashes on circular imports in ext modules

Brett Cannon added the comment: It sounds like Cython has its fix and CPython knows what should eventually be changed in Python 4 to bring extension module initialization closer to how Python module code is initialized. Maybe we should add a warning in some documentation somewhere about this

[issue16392] import crashes on circular imports in ext modules

Stefan Behnel added the comment: Since it's quite possible that this has nothing to do with the frozen part of the importlib specifically, I'm removing that bit from the ticket title. -- title: frozen importlib crashes on circular imports in ext modules - import crashes on circular

[issue16392] import crashes on circular imports in ext modules

Antoine Pitrou added the comment: Are you sure this worked before 3.3? Regardless, it seems you could fix this issue by adding a single line just after the PyModule_Create() call: __pyx_m = PyModule_Create(__pyx_moduledef); #endif if (PyDict_SetItemString(PyImport_GetModuleDict(),

[issue16392] import crashes on circular imports in ext modules

Antoine Pitrou added the comment: A simple test seems to confirm the problem already existed in 3.2. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16392 ___

[issue16392] import crashes on circular imports in ext modules

Antoine Pitrou added the comment: Note that Py_InitModule4 in Python 2 did add the module object to sys.modules (by calling PyImport_AddModule) before returning, but PyModule_Create in Python 3 doesn't. (PEP 3121 doesn't seem to mention PyModule_Create at all, strangely; it seems the PEP

[issue16392] import crashes on circular imports in ext modules

Stefan Behnel added the comment: Hmm, we already do that for packages (i.e. when compiling __init__.py). Looks like this just needs to be done for all modules in Py3. And unless there is a compelling reason for Py_InitModule4() not to do it, I think it should be reverted to its Py2 behaviour.

[issue16392] import crashes on circular imports in ext modules

Antoine Pitrou added the comment: I have detected a compatibility issue when reverting to the 2.x behaviour: extension modules which lie about their name in their PyModuleDef are broken. There are two such modules in 3.3: _io and _decimal. Patch attached, anyway. -- keywords: +patch

[issue16392] import crashes on circular imports in ext modules

Stefan Behnel added the comment: Now that you mention it - wouldn't that suffer from not actually knowing the FQMN? There's that hack in the dynlib loader that stores the package context in a global variable so that the module creation function can figure it out. That might be a reason not to

[issue16392] import crashes on circular imports in ext modules

Antoine Pitrou added the comment: Now that you mention it - wouldn't that suffer from not actually knowing the FQMN? There's that hack in the dynlib loader that stores the package context in a global variable so that the module creation function can figure it out. That might be a reason not