RetroSearch Browse

Mon Dec 22 15:13:55 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-December/041370.html

> > This mostly removes the use of the PYTHONXXX environment variables.
> > Can you explain why you don't want these to work?
> 
> If the user installs our application and has a separate Python
> installation on their machine for which they use those environment
> variables, bad things can happen. I do not want to be in a position
> where I'm told our app doesn't work because of environment variables
> we have no control over, and it is the Wrong Answer to tell the user
> to change their environment.

Fair enough.  (Though you could have built your app to work even if
Python wrote some random stuff to stderr or optimized its bytecode.)

> > Also note that you can already disable *all* use of the environment
> > (not just in Py_Initialize()) by setting the global
> > Py_IgnoreEnvironmentFlag to a non-zero value.  I'd reject that part of
> > the patch for that reason.
> 
> I did not know about or notice this flag when I made the changes ---
> in all the places I looked at the time the environment variables were
> read without such a check, at least as I remember. It certainly makes
> more sense to use the built in support.

Perhaps it's easy to overlook that it's using Py_GETENV() rather than
getenv(); this macro takes tests for Py_IgnoreEnvironmentFlag first.

> > Py_SetSysPaths() might be a valuable addition, but the game you play
> > with the prefiX name is abject. :)
> 
> Sure, whatever. These were made for our own use and later submitted,
> They can be cleaned up as needed.

Please do.  Add some docs too -- undocumented new code isn't very
welcome, since we've already got enough of that. :-)

> > What do you suggest the interpreter should do instead of calling
> > abort()?  This is only called in response to *fatal* errors --
> > situations where raising an exception is *not* an acceptable
> > alternative for various reasons (maybe because it's in a piece of code
> > that is part of the implementation of exceptions, or maybe because a
> > corruption is detected in the very interpreter environment that's
> > needed to raise an exception).
> 
> During initialization if there is a fatal error I can just disable the
> functionality that uses the interpreter --- having my app abort
> because Python cannot initialize for whatever reason is a Bad
> Thing. Similarly with writing messages directly to stderr: I do not
> necessarily want our users to see these since they don't know what to
> do with them.
> 
> > Anout the only alternative I can think of would be a longjmp() call
> > to a handler you have set up, but that can't be safe when the fatal
> > error is discovered in a different thread.
> 
> In our use of Python we build without threads, so the longjmp() would
> work. In the case of threads all bets are off.

So that's an indirect answer to my question: you'd be happy if instead
of calling abort() it would longjmp() to a location you specified?  I
guess a better (more general) solution would be to have a callback
function that's called instead of abort(), and to initialize this with
something that calls abort() by default.  That's a useful feature; if
you upload it to SF with reference to this thread it ought to be
accepted.

--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-December/041370.html below:

[Python-Dev] Improve Python for embedding