On Oct 22, 3:01 pm, Ulf Kronman <[EMAIL PROTECTED]> wrote:
> Hi Graham,
>
> > You should not need to set PYTHONHOME and doing so could cause a lot
> > of problems because if you now run /usr/bin/python2.3 directly or
> > indirectly, it will pick up the wrong installed version of Python
> > modules.
>
> OK, I'll remove it. But why should I want to run Python 2.3?
You might not, but some third party package or even some script
supplied as part of the operating system might want to run Python as /
usr/bin/python explicitly. In this case it will bypass your PATH
variable but still might feasibly inherit your PYTHONHOME variable,
thereby causing the script to fail because it will be using modules
from wrong version of Python.
> As I have
> both
> /Library/Frameworks/Python.framework/Versions/Current/bin and /usr/
> local/bin/ before /usr/bin in my $PATH any python call would pick up
> my new 2.5 version.
>
> > I wouldn't be surprised that a lot of your problems with stuff being
> > installed into wrong place before was because you were setting
> > PYTHONHOME to one version and then running different version of
> > Python.
>
> But I was careful to change that setting in .profile and restart the
> terminal session each time I did a try on a new version.
>
> > In short, do not set PYTHONHOME.
>
> So, why is it there, then? Do you know where I can find any good
> documentation on it?
There isn't any really good documentation on it and other internal
environment variables that I know of. Running 'python -h' or looking
at comments in Modules/getpath.c source code may be the best you get
for PYTHONHOME and some of the other stuff. To partly understand how
it fits into the Python startup sequence you need to understand the
internals of how Python finds its library directory when it starts up.
The comments in Modules/getpath.c can help with some of that,
otherwise need to look at code itself. That one has to go to the
extent of reading the Python source code to fully understand what it
is for is a good sign that the typical user shouldn't be using it for
anything. If it is there for any reason, I'd say it is more for people
who are tinkering with the actual Python code itself.
Only good reason I have seen for fiddling with it is when using
something like mod_python embedded in Apache where you have multiple
versions of Python installed and you can't fiddle the order of PATH
inherited by Apache and so need to set PYTHONHOME in envvars instead.
This is a quite constrained use case and can still cause the same
problems I am warning you about for anything programs executed from
any Apache web applications. In mod_wsgi there is an explicit
directive WSGIPythonHome that can be used to achieve the same affect,
but without setting an environment variable and therefore interfering
with sub process scripts. In this case mod_wsgi is actually calling
internal Py_SetPythonHome() function before actually initialising
Python.
Graham
> > Also, what documentation did you read that said to set PYTHONHOME in
> > the first place. There are only exceptional conditions where you would
> > want to do this and then only when you fully understand what setting
> > it does.
>
> When I had problems with the different versions and paths of python,
> starting the interpreter gave me an error message that it couldn't
> load its modules, and suggested me to set the PYTHONHOME ("consider
> setting PYTHONHOME"), and so I did, and that fixed the problem at that
> time. Now I don't have this problem anymore, so it works fine without
> PYTHONHOME.
>
> // Ulf
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
