PYTHONPATH

A

Algis Kabaila

Hi,

An elementary question that is bugging me, regarding sys.path
values.sys.path can be altered easily, but the changes last for
the current session only. I would like the changes to stay for
several sessions. Is PYTHONPATH a system variable that sets the
path for several sessions and if so, where in the system is it?
Do I need to create one for setting python path for several
sessions?

Your answers will be greatly appreciated!

TIA,
OldAl.
 
H

harrismh777

Algis said:
Is PYTHONPATH a system variable that sets the
path for several sessions and if so, where in the system is it?
Do I need to create one for setting python path for several
sessions?

It can be, and there are lots of ways to accomplish what you want, some
of which depends on the platform you are using. I will show one of the
ways that I accomplish this for my linux sessions. This is based on a
very common snippet of code usually found in the users .profile which
modifies the users path in the even the user has a ~/bin directory---
looks like this:


# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi


When this snippet finds a ~/bin directory in the users ~/ then (and only
then) it modifies the users bash session path with the ~/bin folder at
the head of the path. Well, you can use this same snippet on your system
to modify the PYTHONPATH system variable so that a special folder in
your ~/ directory tree is at or near the head of the sys.path--- looks
like this:


# set PATH so it includes user's private Python if it exists
if [ -d "$HOME/Python" ] ; then
export PYTHONPATH="$HOME/Python:$PYTHONPATH"
fi


You will notice that there is a tiny baby change in the second
snippet... the export. If you want you IDLE launches from the Desktop to
"see" the path set in .profile provide that with the export.

Of course this only works if the Python folder exists in the users ~/
directory tree (or elsewhere, if you code it that way).

By default the sys.path always shows the directory python was opened in,
usually the users home directory. With .profile you can set the path
any way you want... most useful for setting up special test directories
ahead of the "real" code, or for setting up separate directories for
versions--- one for Python26, Python27, and of course Python32.


(there are other ways of accomplishing the same thing, and of course,
this one only really works with *nix systems--- windows is another mess
entirely)

kind regards,
m harris
 
A

Algis Kabaila

snip...
Of course this only works if the Python folder exists in the
users ~/ directory tree (or elsewhere, if you code it that
way).

By default the sys.path always shows the directory python was
opened in, usually the users home directory. With .profile
you can set the path any way you want... most useful for
setting up special test directories ahead of the "real"
code, or for setting up separate directories for versions---
one for Python26, Python27, and of course Python32.


(there are other ways of accomplishing the same thing, and of
course, this one only really works with *nix systems---
windows is another mess entirely)

kind regards,
m harris

My apologies for not stating that I do use a "nix" system -
kubuntu 10.10. I switche to ubuntu/kubuntu from suse some time
ago. Suse had by default a ~/bin directory. On ubuntu/kubuntu
the user needs to create it.

Thank you for your contribution - you adressed exactly the issue
that I wanted to take care of - testing different systems (PyQt
v. PySide, Python 2.7 v Python 3.2 etc.)

It is a significant help!

Sorry I can not address you by name, as your signature is
suggestive that it may start with M and that Harris is your
surname (or pseudo name). You have been most helpful!

OldAl.
 
J

jmfauth

By default the sys.path always shows the directory python was opened in,
usually the users home directory. With  .profile  you can set the path
any way you want... most useful for setting up special test directories
ahead of the "real" code, or for setting up separate directories for
versions--- one for Python26, Python27, and of course Python32.

(there are other ways of accomplishing the same thing, and of course,
this one only really works with *nix systems--- windows is another mess
entirely)


I belong to those who are very happy with the Python
installations on Windows platform (thanks MvL, this should
be said) and I hope it will continue like this.

I do not see any mess here. Every Python version lives in
its own isolated directory, including \site-packages.
That means I can keep, eg, a Python 2.5 application (*) which
is using PIL, wxPython and numpy in a running state, while
developping new applications with other Python versions or
porting that application (*) to another Python version. And
that on all Windows versions (Win2K, XP, Vista, Win7) modulo
the underlaying os-libs compatibility, but that's the same
problem on all os, especially for the GUI libs.

I'm using Python since ver 1.5.6 and I never set any
PYTHONPATH environment variable.

A final word about sys.path. This is is my mind the
most clever idea of Python. I have the feeling, no
offense here, you are not understanding it very well.
The sys.path is some kind of *dynamic* environment
variable and has basically or primarily nothing to do
with a user directory.

jmf
 
A

Algis Kabaila

I belong to those who are very happy with the Python
installations on Windows platform (thanks MvL, this should
be said) and I hope it will continue like this.

I do not see any mess here. Every Python version lives in
its own isolated directory, including \site-packages.
That means I can keep, eg, a Python 2.5 application (*) which
is using PIL, wxPython and numpy in a running state, while
developping new applications with other Python versions or
porting that application (*) to another Python version. And
that on all Windows versions (Win2K, XP, Vista, Win7) modulo
the underlaying os-libs compatibility, but that's the same
problem on all os, especially for the GUI libs.

I'm using Python since ver 1.5.6 and I never set any
PYTHONPATH environment variable.

A final word about sys.path. This is is my mind the
most clever idea of Python. I have the feeling, no
offense here, you are not understanding it very well.
The sys.path is some kind of *dynamic* environment
variable and has basically or primarily nothing to do
with a user directory.

jmf

On invocation of IDLE, sys.path does contain the path to home
directory (on nix /home/<name>; on my PC it is /home/ak) In
Bash that home directory is accessible through bash variable
$HOME. Once a program is executed from the "Python Shell" (of
IDLE), the $HOME directory is replace by the directory of the
program, whatever that is. Yes, sys.path is dynamic and it can
be easily changed from Python, but the changes are discarded
once the Python is restarted. Hence my interest in shell
variable PYTHONPATH, accessible from bash as $PYTHONPATH.

I have no need of Windows and no longer use it at all, yet I
want my programs to be portable to all main platforms, hence my
enthusiastic support for all things Python.

Thanks for all contributions and ALL includes windows et al.

OldAl.
 
H

harrismh777

jmfauth said:
I belong to those who are very happy with the Python
installations on Windows platform . . .
I do not see any mess here.

Sorry, I was speaking of a technical mess, not a user's mess.

What I was alluding to specifically is explained very well in PEP 394.
The technical reasoning the PEP 394 author uses for *not* addressing the
Windows issue (for 394) is the 'mess'. Its just technically difficult to
setup easily configured concurrent environments on the Windows platform,
primarily due to the way the platform was designed--- closed and
proprietary--- with little to no community input. I think PEP 397
describes a Windows solution to the problem PEP 394 addresses.

Also, the reason I even mentioned Windows at all, is that I realize that
more than one platform is active in the Python community. That is a
difficulty for posting tips without specifying the applicable platform,
if the tip only applies to *nix for instance. Please, in no way did I
intend to offend the Windows Python users. Python enhances the life
experience of Windows users the world over for which I am thankful. Peace.

kind regards,
m harris
 
S

Steven D'Aprano

Its just technically difficult to
setup easily configured concurrent environments on the Windows platform,
primarily due to the way the platform was designed--- closed and
proprietary--- with little to no community input.

I believe that is incorrect. In my opinion, a better explanation for the
difficulty faced by Windows users is that this is a side-effect of
Windows starting life as a single-user operating system. Various
proprietary Unixes -- and all Unixes started off life as closed and
proprietary -- and other proprietary but multi-user OSes, such as VMS,
are more easily configured.
 
H

harrismh777

Steven said:
In my opinion, a better explanation for the
difficulty faced by Windows users is that this is a side-effect of
Windows starting life as a single-user operating system.

Yes, that is my opinion as well.

Windows for better or worse is plagued by "cruft" that dates back to the
CP/M 80 and DOS days. Not just single user systems, but also
single-threaded (or single process) systems.

When I speak of Windows design, its really a tongue in cheek thing...
its really a matter of non-design in my view. Over the years it
[windows] has crofted into the technical mess it is today.

In retrospect, in many ways this is why I am relatively patient with the
Python3 development direction. While I think its non-compatibility may
hurt in the short term, the long term goal of stream-lining the language
will make for a much better Python future. Essentially, the python team
said, "Look, python2 sucks... ," and then they went about figuring out
what Python would look like had it been "designed" right in the first
place. Whalla, Python3. So after years and years of practical experience
with the language Python is getting the face lift it deserves, and is
going to be one gorgeous lady when finished.

Windows, on the other hand, never had the humility of the Python team in
the respect of willingness to change in the face of bloat, or cruft.
Windows stuck it out with ultimate backward compatibility issues and a
plethora of CP/M DOS carry-overs that are just not helpful... not to
mention not realizing that a desk machine can *also* be a server--! In
their insane attack on third party browsers their ultimate and
quintessential design error was integrating the browser/desktop while
designing networking as an application (needing protection from third
parties). They should have taken the *nix approach of integrating the
network (no third party access to the kernel) and making the desktop an
application. In this, gnulinux is the correct design choice (OSX does
this as well... based on FreeBSD). Windows may come around in the
future; if they survive.

There are many reasons for how and why Windows has usability and
extensibility issues. At some point I expect to see Microsoft realizing
these errors and correcting by completely redesigning their OS. This
time around making it open and configurable. They might even get some of
the love back... who knows.

kind regards,
m harris
 
M

MRAB

On 18/04/2011 05:37, harrismh777 wrote:
[snip]
In retrospect, in many ways this is why I am relatively patient with the
Python3 development direction. While I think its non-compatibility may
hurt in the short term, the long term goal of stream-lining the language
will make for a much better Python future. Essentially, the python team
said, "Look, python2 sucks... ," and then they went about figuring out
what Python would look like had it been "designed" right in the first
place. Whalla, Python3. So after years and years of practical experience
with the language Python is getting the face lift it deserves, and is
going to be one gorgeous lady when finished.
[snip]
I think you mean "Voilà, Python3."

And I doubt that the Python team said "Look, python2 sucks...", but
rather "Look, Python2 has some cruft which needs to be removed".
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top