PYTHONPATH

Discussion in 'Python' started by Algis Kabaila, Apr 15, 2011.

  1. 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
     
    Algis Kabaila, Apr 15, 2011
    #1
    1. Advertising

  2. Algis Kabaila

    harrismh777 Guest

    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
     
    harrismh777, Apr 16, 2011
    #2
    1. Advertising

  3. 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
     
    Algis Kabaila, Apr 16, 2011
    #3
  4. Algis Kabaila

    jmfauth Guest

    On 16 avr, 06:16, harrismh777 <> 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
     
    jmfauth, Apr 16, 2011
    #4
  5. On Saturday 16 April 2011 20:03:22 jmfauth wrote:
    > On 16 avr, 06:16, harrismh777 <> 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
     
    Algis Kabaila, Apr 16, 2011
    #5
  6. Algis Kabaila

    harrismh777 Guest

    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
     
    harrismh777, Apr 17, 2011
    #6
  7. 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
     
    Steven D'Aprano, Apr 17, 2011
    #7
  8. Algis Kabaila

    harrismh777 Guest

    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
     
    harrismh777, Apr 18, 2011
    #8
  9. Algis Kabaila

    MRAB Guest

    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".
     
    MRAB, Apr 18, 2011
    #9
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Harald Kirsch

    jython and PYTHONPATH

    Harald Kirsch, Jun 28, 2003, in forum: Python
    Replies:
    1
    Views:
    1,281
    Ype Kingma
    Jun 30, 2003
  2. vincent delft

    CGIHTTPserver looze PYTHONPATH

    vincent delft, Jul 13, 2003, in forum: Python
    Replies:
    1
    Views:
    456
    vincent_delft
    Jul 13, 2003
  3. klappnase

    Re: Python..Tkinter..PYTHONPATH..

    klappnase, Jul 30, 2003, in forum: Python
    Replies:
    0
    Views:
    401
    klappnase
    Jul 30, 2003
  4. Steven Taschuk

    Re: Python..Tkinter..PYTHONPATH..

    Steven Taschuk, Jul 30, 2003, in forum: Python
    Replies:
    0
    Views:
    412
    Steven Taschuk
    Jul 30, 2003
  5. Rami A. Kishek

    PythonPath not working with 2.2.3 on Win ME

    Rami A. Kishek, Aug 16, 2003, in forum: Python
    Replies:
    0
    Views:
    342
    Rami A. Kishek
    Aug 16, 2003
Loading...

Share This Page