RetroSearch Browse

Sat Aug 23 08:34:10 EDT 2003 · https://mail.python.org/pipermail/python-dev/2003-August/037780.html

> 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/)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-August/037780.html below:

[Python-Dev] Embedded python module search path