[Python-Dev] Embedded python module search path
Guido van Rossum
guido at python.org
Sat Aug 23 08:34:10 EDT 2003
> As I look at Py_Initialize() further, I see some other 'features' that
> could be problematic when embedding: particularly the calls to
> Py_FatalError. An embedding application may be able to continue even
> if the Python interpreter cannot be initialized... certainly it should
> be up to the embedding application on how to handle the error, instead
> of having abort() called for it.
Unclear. You cannot completely avoid the possibility of
Py_FatalError() being called in Python. The Py_FatalError() calls in
Py_Initialize() are no different than the ones elsewhere in Python:
they are only expected when you run out of memory in this stage.
What might be useful would be a way for an embedding app to "hook"
Py_FatalError() though, so that the embedding app can direct the error
message to its own logging stream.
> It would also be nice if there were no calls fprintf and friends
> within the initialization path when doing embedded initialization.
Right. Apart from a few inside debug #ifdefs, I see one or two that
might realistically come up, and that should be fixed. In particular
the line
fprintf(stderr, "python: Can't reopen .pyc file\n");
should probably be replaced by a call to PySys_WriteStderr(). I'm not
sure what to do about the line
fprintf(stderr, "lost sys.stderr\n");
because if sys.stderr can't be found, there's no other place to send
an error. Maybe in addition to a hookable Py_FatalError() we should
also make PySys_WriteStderr() hookable. Of course it should always
first try sys.stderr, but if that fails it should fall back to the
hook rather than to stdio's stderr.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev
mailing list