Gregory Szorc <gregory.sz...@gmail.com> added the comment:
Having approached this with a fresh brain, I was able to port PyOxidizer to use the multi-phase initialization API with minimal regressions! The relevant code exists at https://github.com/indygreg/PyOxidizer/blob/b5aa2b3a96dbd01e9d78857e124f1052f42f86c6/pyembed/src/interpreter.rs#L550. Here's the sequence: 1) Initialize core 2) Import our custom built-in extension module 3) Run some more code to initialize our extension module (update sys.meta_path, etc) 4) Initialize main 5) Remove PathFinder if filesystem imports are disabled #5 isn't ideal: I would prefer an API to disable the registration of that importer completely. But PyOxidizer's importer is first on sys.meta_path and PathFinder shouldn't come into play. So it should be mostly harmless. A super minor paper cut is the lack of a PyConfig_SetBytesString() variant for PyWideStringList_Append(). It was slightly annoying having to convert a POSIX char* path to a wchar_t* since paths on POSIX are bytes. Another potential area for improvement is around error handling before main is initialized. I'd like to represent PyErr raised during initialization as a Rust String, as PyErr isn't appropriate since there isn't a fully initialized Python interpreter. However, I discovered that serializing PyErr to strings is a bit brittle before main is initialized. e.g. https://docs.python.org/3/faq/extending.html#id11 says to use PyErr_Print() and replace sys.stdout. But sys.stdout isn't initialized yet and I'm scared to touch it. It also appears various functions in traceback rely on facilities from an initialized interpreter (such as finding sources). It would be useful if there were some kind of PyErr API that returned a PyString (or PyStatus) and was guaranteed to work before main is initialized. Overall, the new code in PyOxidizer is much, much cleaner! Thanks again for the new API! ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue40333> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
