Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #3254 > unrolled thread

PYTHONPATH

Back to article view | Back to comp.lang.python

Contents

  PYTHONPATH Algis Kabaila <akabaila@pcug.org.au> - 2011-04-15 18:33 +1000
    Re: PYTHONPATH harrismh777 <harrismh777@charter.net> - 2011-04-15 23:16 -0500
      Re: PYTHONPATH Algis Kabaila <akabaila@pcug.org.au> - 2011-04-16 17:28 +1000
      Re: PYTHONPATH jmfauth <wxjmfauth@gmail.com> - 2011-04-16 03:03 -0700
        Re: PYTHONPATH Algis Kabaila <akabaila@pcug.org.au> - 2011-04-16 20:57 +1000
        Re: PYTHONPATH harrismh777 <harrismh777@charter.net> - 2011-04-17 01:14 -0500
          Re: PYTHONPATH Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-17 08:43 +0000
            Re: PYTHONPATH harrismh777 <harrismh777@charter.net> - 2011-04-17 23:37 -0500
              Re: PYTHONPATH MRAB <python@mrabarnett.plus.com> - 2011-04-18 16:31 +0100

#3254 — PYTHONPATH

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

[toc] | [next] | [standalone]

#3288

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

[toc] | [prev] | [next] | [standalone]

#3303

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

[toc] | [prev] | [next] | [standalone]

#3309

On 16 avr, 06:16, harrismh777 <harrismh...@charter.net> 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

[toc] | [prev] | [next] | [standalone]

#3310

On Saturday 16 April 2011 20:03:22 jmfauth wrote:
> On 16 avr, 06:16, harrismh777 <harrismh...@charter.net> 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

[toc] | [prev] | [next] | [standalone]

#3373

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

[toc] | [prev] | [next] | [standalone]

#3379

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

[toc] | [prev] | [next] | [standalone]

#3454

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

[toc] | [prev] | [next] | [standalone]

#3490

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web