It’s fine to export both the old and new init functions - for normal module import the new functions will get used preferentially, but you can leave the old ones around for inittab usage.
This almost works, but I’m hitting an issue that maybe wasn’t foreseen?
In a PyO3 test that uses the inittab, I hit a SystemError inside CPython:
---- src/lib.rs - doc_test::guide_pfr_calling_existing_code_md (line 625) stdout ----
Test executable failed (exit status: 1).
stderr:
Error: PyErr { type: <class 'SystemError'>, value: SystemError('module foo: Py_mod_name used with PyModuleDef'), traceback: Some("Traceback (most recent call last):\n File \"<string>\", line 1, in <module>\n") }
This comes from here:
I think maybe that check should be relaxed, and only object if e.g. original_def->m_name is non-NULL when Py_mod_name is defined.
@encukou does that seem reasonable?
If that’s not possible, I have a workaround in PyO3. If I define two sets of slots - one for PyModExport and one for PyModuleDef, then it works. But it’s kind of ugly. I guess we can clean this up though if a future Python version adds an API for adding modules to the inittab without using the legacy module initialization hook. See this commit if you’re curious what the workaround looks like.