Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > PYTHONPATH

Reply
Thread Tools

PYTHONPATH

 
 
Algis Kabaila
Guest
Posts: n/a
 
      04-15-2011
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.

--
Algis
http://akabaila.pcug.org.au/StructuralAnalysis.pdf
 
Reply With Quote
 
 
 
 
harrismh777
Guest
Posts: n/a
 
      04-16-2011
Algis Kabaila wrote:
> 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




 
Reply With Quote
 
 
 
 
Algis Kabaila
Guest
Posts: n/a
 
      04-16-2011
On Saturday 16 April 2011 14:16:59 harrismh777 wrote:
> Algis Kabaila wrote:
> > 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?

>
>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.

--
Algis
http://akabaila.pcug.org.au/StructuralAnalysis.pdf
 
Reply With Quote
 
jmfauth
Guest
Posts: n/a
 
      04-16-2011
On 16 avr, 06:16, harrismh777 <(E-Mail Removed)> wrote:


> 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
 
Reply With Quote
 
Algis Kabaila
Guest
Posts: n/a
 
      04-16-2011
On Saturday 16 April 2011 20:03:22 jmfauth wrote:
> On 16 avr, 06:16, harrismh777 <(E-Mail Removed)> wrote:
> > 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


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.
--
Algis
http://akabaila.pcug.org.au/StructuralAnalysis.pdf
 
Reply With Quote
 
harrismh777
Guest
Posts: n/a
 
      04-17-2011
jmfauth wrote:
> 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

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      04-17-2011
On Sun, 17 Apr 2011 01:14:54 -0500, harrismh777 wrote:

> 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.


--
Steven
 
Reply With Quote
 
harrismh777
Guest
Posts: n/a
 
      04-18-2011
Steven D'Aprano wrote:
> 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


 
Reply With Quote
 
MRAB
Guest
Posts: n/a
 
      04-18-2011
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".
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
PythonPath not working with 2.2.3 on Win ME Rami A. Kishek Python 0 08-16-2003 06:54 AM
Re: Python..Tkinter..PYTHONPATH.. Steven Taschuk Python 0 07-30-2003 05:21 PM
Re: Python..Tkinter..PYTHONPATH.. klappnase Python 0 07-30-2003 10:12 AM
CGIHTTPserver looze PYTHONPATH vincent delft Python 1 07-13-2003 06:07 PM
jython and PYTHONPATH Harald Kirsch Python 1 06-29-2003 11:28 PM



Advertisments