[Python-Dev] Improve Python for embedding (original) (raw)

Guido van Rossum guido at python.org
Mon Dec 22 15:13:55 EST 2003

> 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 PyInitialize()) by setting the global > PyIgnoreEnvironmentFlag 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.

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

More information about the Python-Dev mailing list