Re: PythonPath / sys.path

[Thomas Passin]

On 5/15/2023 3:26 AM, Barry wrote:




On 15 May 2023, at 05:39, Thomas Passin  wrote:

On 5/14/2023 11:08 PM, Chris Angelico wrote:

On Mon, 15 May 2023 at 12:07, Thomas Passin  wrote:
Well, no, why would you assume that?  I started to use Linux - in VMs -
because I had to make sure that my cross-platform java/jython Tomcat
program would work right on Linux.  Why, for example, would I think to
install Idle from the package manager when it, or things like that, were
always in my experience installed with pip? For that matter, "sudo
apt-get install pip" won't install pip.  You need to use a different
name, and it may or may not be different for different distros.

If you EVER had to install something other than a Python package, you
would have had to make use of the system package manager. You're
right, there are multiple obvious ways to install Idle, but that
doesn't mean that the package manager isn't one of them.


Yes, after a while I came to realize that missing Python pieces might be 
available from the package manager.  That doesn't mean it's obvious, or easy to 
discover just what names to use.  And sometimes one has to add a new external 
repository.  Personally, I don't find it easy to scroll through hundreds of 
lines in the synaptics search results looking for something whose name I can 
only partly guess at.  If I know the command line equivalent for a search, I 
could do a grep and that would probably be more focused.  But trying to work 
with a dozen different distros because various clients might use them - it's 
hard to keep details straight.

Anyway, there's no point in trying to convince me that I could have understood 
everything at the start that I may have learned later.  I'm just interested in 
passing on things I've learned along that way that a newcomer to Python in 
Linux may not realize.


Being a Fedora user i needed to learn how to install missing pieces of pyrhon 
on ubuntu.

We searches for:
ubuntu install pip
Ubuntu install idle

Both provide lots of answers. Did your searches fail to turn up answers?


No, that's what I had to do too, that and scan through package manager 
searches.


--
https://mail.python.org/mailman/listinfo/python-list

Re: PythonPath / sys.path

[Chris Angelico]

On Mon, 15 May 2023 at 14:38, Thomas Passin  wrote:
>
> On 5/14/2023 11:08 PM, Chris Angelico wrote:
> > On Mon, 15 May 2023 at 12:07, Thomas Passin  wrote:
> >> Well, no, why would you assume that?  I started to use Linux - in VMs -
> >> because I had to make sure that my cross-platform java/jython Tomcat
> >> program would work right on Linux.  Why, for example, would I think to
> >> install Idle from the package manager when it, or things like that, were
> >> always in my experience installed with pip? For that matter, "sudo
> >> apt-get install pip" won't install pip.  You need to use a different
> >> name, and it may or may not be different for different distros.
> >
> > If you EVER had to install something other than a Python package, you
> > would have had to make use of the system package manager. You're
> > right, there are multiple obvious ways to install Idle, but that
> > doesn't mean that the package manager isn't one of them.
>
> Yes, after a while I came to realize that missing Python pieces might be
> available from the package manager.  That doesn't mean it's obvious, or
> easy to discover just what names to use.

Define "obvious". Nothing is completely intuitive, and at some point,
you HAVE to learn things. With any modern GUI desktop system, I am
going to assume that "click on the thing" counts as obvious, even
though it, like everything else, has to be learned. Once it's been the
exact same UI for everything so far, wouldn't it count as obvious?

Use your package manager.

> And sometimes one has to add a
> new external repository.

Why? When do you need to? Use the system package manager and the core
repositories.

> Personally, I don't find it easy to scroll
> through hundreds of lines in the synaptics search results looking for
> something whose name I can only partly guess at.

I don't use Synaptic, so I have no idea what the problem is here, but
there are really only a couple of plausible package names:

1) idle
2) python-idle

It's possible you'll need to install idle3 or python3-idle to get the
latest, but if so, one of the above names would have installed Idle
from Python 2.7.

This is a matter of learning patterns, which most humans are good at.
But even if you haven't yet, your absolute worst case is a
straight-forward search ("apt-cache search idle", "apt search idle",
or using a GUI tool to search). Assuming you haven't added every
repository you can find, in a wild attempt to worsen your computer's
stability and security, this should produce roughly a hundred results
(I got 123 on my search), many of which are clearly not what you want.
This is really not that many to skim over.

> If I know the command
> line equivalent for a search, I could do a grep and that would probably
> be more focused.

Did you try searching the web for "apt search for package" or anything
like that? The command is "apt search" or "apt-cache search" (they're
slightly different in output but they'll give broadly the same info)
and this information is easily found on the internet.

> But trying to work with a dozen different distros
> because various clients might use them - it's hard to keep details straight.

Okay, that's fair. You should only have to work with a small number of
package managers, but the more different the distros are, the less
effective you'll be at intuitively guessing the package names. But you
should still be able to search.

> Anyway, there's no point in trying to convince me that I could have
> understood everything at the start that I may have learned later.  I'm
> just interested in passing on things I've learned along that way that a
> newcomer to Python in Linux may not realize.

I'm not saying you should have understood everything at the start; but
I am saying that all the answers are out there if you look for them.
Making blanket statements like:

> Ubuntu, like many other Linux distros,
> does not come with pip and Tk (needed for Idle) installed, and it's not
> so obvious how to install them.

are *EXTREMELY* unfair, since you are naming a single distro and then
blaming "many other" distros by association, giving the highly false
impression that Linux is nearly impossible to use.

It is, in fact, very easy to install these things on many Linux
distros. You just have to be willing to get to know your own system
(since most people are only running one distro).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PythonPath / sys.path

[Barry]

> On 15 May 2023, at 05:39, Thomas Passin  wrote:
> 
> On 5/14/2023 11:08 PM, Chris Angelico wrote:
>>> On Mon, 15 May 2023 at 12:07, Thomas Passin  wrote:
>>> Well, no, why would you assume that?  I started to use Linux - in VMs -
>>> because I had to make sure that my cross-platform java/jython Tomcat
>>> program would work right on Linux.  Why, for example, would I think to
>>> install Idle from the package manager when it, or things like that, were
>>> always in my experience installed with pip? For that matter, "sudo
>>> apt-get install pip" won't install pip.  You need to use a different
>>> name, and it may or may not be different for different distros.
>> If you EVER had to install something other than a Python package, you
>> would have had to make use of the system package manager. You're
>> right, there are multiple obvious ways to install Idle, but that
>> doesn't mean that the package manager isn't one of them.
> 
> Yes, after a while I came to realize that missing Python pieces might be 
> available from the package manager.  That doesn't mean it's obvious, or easy 
> to discover just what names to use.  And sometimes one has to add a new 
> external repository.  Personally, I don't find it easy to scroll through 
> hundreds of lines in the synaptics search results looking for something whose 
> name I can only partly guess at.  If I know the command line equivalent for a 
> search, I could do a grep and that would probably be more focused.  But 
> trying to work with a dozen different distros because various clients might 
> use them - it's hard to keep details straight.
> 
> Anyway, there's no point in trying to convince me that I could have 
> understood everything at the start that I may have learned later.  I'm just 
> interested in passing on things I've learned along that way that a newcomer 
> to Python in Linux may not realize.

Being a Fedora user i needed to learn how to install missing pieces of pyrhon 
on ubuntu.

We searches for:
ubuntu install pip
Ubuntu install idle

Both provide lots of answers. Did your searches fail to turn up answers?

Barry


> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PythonPath / sys.path

[Thomas Passin]

On 5/14/2023 11:08 PM, Chris Angelico wrote:

On Mon, 15 May 2023 at 12:07, Thomas Passin  wrote:

Well, no, why would you assume that?  I started to use Linux - in VMs -
because I had to make sure that my cross-platform java/jython Tomcat
program would work right on Linux.  Why, for example, would I think to
install Idle from the package manager when it, or things like that, were
always in my experience installed with pip? For that matter, "sudo
apt-get install pip" won't install pip.  You need to use a different
name, and it may or may not be different for different distros.


If you EVER had to install something other than a Python package, you
would have had to make use of the system package manager. You're
right, there are multiple obvious ways to install Idle, but that
doesn't mean that the package manager isn't one of them.


Yes, after a while I came to realize that missing Python pieces might be 
available from the package manager.  That doesn't mean it's obvious, or 
easy to discover just what names to use.  And sometimes one has to add a 
new external repository.  Personally, I don't find it easy to scroll 
through hundreds of lines in the synaptics search results looking for 
something whose name I can only partly guess at.  If I know the command 
line equivalent for a search, I could do a grep and that would probably 
be more focused.  But trying to work with a dozen different distros 
because various clients might use them - it's hard to keep details straight.


Anyway, there's no point in trying to convince me that I could have 
understood everything at the start that I may have learned later.  I'm 
just interested in passing on things I've learned along that way that a 
newcomer to Python in Linux may not realize.


--
https://mail.python.org/mailman/listinfo/python-list

Re: PythonPath / sys.path

[Chris Angelico]

On Mon, 15 May 2023 at 12:07, Thomas Passin  wrote:
> Well, no, why would you assume that?  I started to use Linux - in VMs -
> because I had to make sure that my cross-platform java/jython Tomcat
> program would work right on Linux.  Why, for example, would I think to
> install Idle from the package manager when it, or things like that, were
> always in my experience installed with pip? For that matter, "sudo
> apt-get install pip" won't install pip.  You need to use a different
> name, and it may or may not be different for different distros.

If you EVER had to install something other than a Python package, you
would have had to make use of the system package manager. You're
right, there are multiple obvious ways to install Idle, but that
doesn't mean that the package manager isn't one of them.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PythonPath / sys.path

[Thomas Passin]

On 5/14/2023 7:28 PM, Chris Angelico wrote:

On Mon, 15 May 2023 at 09:22, Thomas Passin  wrote:

You made a little slam against Windows, but you will find it harder to
get things working on Linux.  Ubuntu, like many other Linux distros,
does not come with pip and Tk (needed for Idle) installed, and it's not
so obvious how to install them.


The assumption on Linux is usually that you know how to use your
system's package manager. And on Debian and Ubuntu specifically, it's
about as easy as you would want: "apt install idle". That'll pull in
everything you should need. I don't know about other distros but I
would expect that it's approximately as easy.

Maybe that's not obvious if you come from Windows, but I'd guess that
most desktop Linux users will have at least a passing familiarity with
their package manager, making this a perfectly obvious way to get new
software.


Well, no, why would you assume that?  I started to use Linux - in VMs - 
because I had to make sure that my cross-platform java/jython Tomcat 
program would work right on Linux.  Why, for example, would I think to 
install Idle from the package manager when it, or things like that, were 
always in my experience installed with pip? For that matter, "sudo 
apt-get install pip" won't install pip.  You need to use a different 
name, and it may or may not be different for different distros.


No, I came to use Linux they way I said, but I didn't find those things 
to be obvious.  That's why I've started mentioning them on this list 
when it seems like they might be useful.


Furthermore, people have been having trouble getting certain PyQt 
programs working on Ubuntu 22.04 (and 20.xx before it) (yes, I know, not 
what the OP asked about). The solution is pretty non-obvious and 
requires a particular .so library file to be installed, if you can 
discover which one and how to do that.  I mention this in support of 
what I said about a Windows Python user being likely to find things 
harder, not easier, on Linux.


And please, let's not start a flame war about this!  I'm passing on what 
I've experienced, that's all.  Yes, I know that there are some Python 
packages that need to be built and that usually works better on Linux. 
And I'll agree that some Python programs are snappier to load and run on 
Linux than on the same machine running Windows, even in a Linux VM guest.


--
https://mail.python.org/mailman/listinfo/python-list

Re: PythonPath / sys.path

[Chris Angelico]

On Mon, 15 May 2023 at 09:22, Thomas Passin  wrote:
> You made a little slam against Windows, but you will find it harder to
> get things working on Linux.  Ubuntu, like many other Linux distros,
> does not come with pip and Tk (needed for Idle) installed, and it's not
> so obvious how to install them.

The assumption on Linux is usually that you know how to use your
system's package manager. And on Debian and Ubuntu specifically, it's
about as easy as you would want: "apt install idle". That'll pull in
everything you should need. I don't know about other distros but I
would expect that it's approximately as easy.

Maybe that's not obvious if you come from Windows, but I'd guess that
most desktop Linux users will have at least a passing familiarity with
their package manager, making this a perfectly obvious way to get new
software.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PythonPath / sys.path

[Thomas Passin]

On 5/14/2023 3:00 PM, Grizzy Adams via Python-list wrote:

Sunday, May 14, 2023  at 11:11, Mats Wichmann wrote:
Re: PythonPath / sys.path (at least in part)

[snip]

I have since moved up (a little) so only ~4 years old, I then updated pip from
9.x to 19.1

reason its an old version is it's an old PC (XpPro), if I start to get passable

at this I will try it on my Ubuntu box which is running 22.04 (latest LTS) and
23.04, (23.10 daily builds soon) I took a look and it seems I "may" have to
play a little to get IDLE on (if it's not in the normal repo's)

I seem to have managed to sort "PythonPath / sys.path" the environment variable

is working, so I can now import my_work without any other hassle, which is
good, now I find that some of the files which worked a treat from GUI, Editor
(F5) or terminal but don't do the same once saved and imported later, I'm sure
it's me, I have come from VB/VBA, Delphi and a (very) little C++, and am still
working through the python tutorial, trying not to skip ahead (ok I did skip
"Hello World" :->) so I may end up asking some (senior moment) newbie
questions, I will try hard to work it out myself first

Thanks to all who got me thus far


Good to hear you can run your program.  For future reference, when you 
talked about setting PYTHONPATH, it would have been helpful to know just 
what you did when you tried to set it.


If you plan to use this directory location much of the time, two good 
ways to do so are 1) putting that path in a .pth file in the 
site-packages directory, or 2) launching Python using a batch file that 
sets PYTHONPATH first, then runs Python.  On Windows, in a batch file 
you should use SETLOCAL before setting PYTHONPATH and ENDLOCAL at the 
end of the batch file.  That's the easiest way to remove the PYTHONPATH 
variable after you are done with it.


You made a little slam against Windows, but you will find it harder to 
get things working on Linux.  Ubuntu, like many other Linux distros, 
does not come with pip and Tk (needed for Idle) installed, and it's not 
so obvious how to install them.


For your old computer, I added an external 1TB solid state drive (Note: 
not  a usb stick) to a decade-old Sony VAIO and installed Linux Mint to 
the SSD.  It's got pretty decent responsiveness and all the old hardware 
is supported out of the box.


--
https://mail.python.org/mailman/listinfo/python-list

Re: PythonPath / sys.path

[Eryk Sun]

On 5/13/23, Grizzy Adams via Python-list  wrote:
>
> I have tried adding my dir in registry to the existing PythonPath
>
> [HKEY_CURRENT_USER\Software\Python\PythonCore\3.4\PythonPath]
> @="D:\\Shades\\Tools\\Python\\Lib;D:\\Shades\\Tools\\Python\\DLLs"
>
> that did not help,

The default value of the above registry key is only used if Python
can't calculate the default sys.path based on searching for "os.py",
the landmark module in the standard library. This can happen sometimes
when Python is embedded or run from a symlink.

The default value of each subkey of
"[HKCU|HKLM]\Software\Python\PythonCore\\PythonPath", on the
other hand, usually does extend sys.path. Except that running Python
with the -E or -I command-line options (both supported by Python 3.4)
makes the interpreter ignore PYTHON* environment variables, including
PYTHONPATH, as well as registry settings such as subkeys of
"PythonPath".

Even with the -E or -I command-line options, .pth files in the system
site-packages are still processed. A .pth file can be used to extend
sys.path as long as the site module is imported, i.e. as long as the
-S command-line option isn't used. One difference, however, is that
directories in .pth files are appended to sys.path and thus do not
override the standard library.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PythonPath / sys.path

[Mats Wichmann]

On 5/14/23 13:00, Grizzy Adams via Python-list wrote:

Sunday, May 14, 2023  at 11:11, Mats Wichmann wrote:
Re: PythonPath / sys.path (at least in part)


On 5/14/23 10:43, Barry wrote:



I take it you have business reasons to use an obsolete version python.
Where did you get your version of python from?



In fact, a *nine* year old version of Python that reached end-of-life
four years ago.



Just sayin'



Python version shouldn't have anything to do with the sys.path, though.


I must have slept a while

Python 3.4.10 (default, Jul 14 2019, 14:41:03) [MSC v.1600 32 bit (Intel)] on
win32

Actually I did have 3..4.3 when I asked the question (first time) because I
could only find 3.4.10 as src and did not feel I was able to compile it with
any certainty ;->)

I have since moved up (a little) so only ~4 years old, I then updated pip from
9.x to 19.1

reason its an old version is it's an old PC (XpPro), if I start to get passable


yes, it's true that 3.4 was the last release supported on XP, so that's 
a pretty good reason (of course we can ask why still running XP, but I 
do understand old machines...)



at this I will try it on my Ubuntu box which is running 22.04 (latest LTS) and
23.04, (23.10 daily builds soon) I took a look and it seems I "may" have to
play a little to get IDLE on (if it's not in the normal repo's)


IDLE is still supported, you shouldn't have any trouble getting it.

https://packages.ubuntu.com/lunar/idle


--
https://mail.python.org/mailman/listinfo/python-list

Re: PythonPath / sys.path

[Grizzy Adams via Python-list]

Sunday, May 14, 2023  at 11:11, Mats Wichmann wrote:
Re: PythonPath / sys.path (at least in part)

>On 5/14/23 10:43, Barry wrote:

>> I take it you have business reasons to use an obsolete version python.
>> Where did you get your version of python from?

>In fact, a *nine* year old version of Python that reached end-of-life 
>four years ago.

>Just sayin'

>Python version shouldn't have anything to do with the sys.path, though.

I must have slept a while

Python 3.4.10 (default, Jul 14 2019, 14:41:03) [MSC v.1600 32 bit (Intel)] on 
win32

Actually I did have 3..4.3 when I asked the question (first time) because I 
could only find 3.4.10 as src and did not feel I was able to compile it with 
any certainty ;->)

I have since moved up (a little) so only ~4 years old, I then updated pip from 
9.x to 19.1

reason its an old version is it's an old PC (XpPro), if I start to get passable 

at this I will try it on my Ubuntu box which is running 22.04 (latest LTS) and 
23.04, (23.10 daily builds soon) I took a look and it seems I "may" have to 
play a little to get IDLE on (if it's not in the normal repo's)

I seem to have managed to sort "PythonPath / sys.path" the environment variable 

is working, so I can now import my_work without any other hassle, which is 
good, now I find that some of the files which worked a treat from GUI, Editor 
(F5) or terminal but don't do the same once saved and imported later, I'm sure 
it's me, I have come from VB/VBA, Delphi and a (very) little C++, and am still 
working through the python tutorial, trying not to skip ahead (ok I did skip 
"Hello World" :->) so I may end up asking some (senior moment) newbie 
questions, I will try hard to work it out myself first

Thanks to all who got me thus far

Grizz
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PythonPath / sys.path

[Mats Wichmann]

On 5/14/23 10:43, Barry wrote:


I take it you have business reasons to use an obsolete version python.
Where did you get your version of python from?


In fact, a *nine* year old version of Python that reached end-of-life 
four years ago.


Just sayin'

Python version shouldn't have anything to do with the sys.path, though.


--
https://mail.python.org/mailman/listinfo/python-list

Re: PythonPath / sys.path

[Barry]

> On 14 May 2023, at 16:32, Grizzy Adams via Python-list 
>  wrote:
> 
> Hi All
> 
> My first post (repeated)
> 
> I am having a problem with PythonPath / sys.path
> 
> I have a dir where I keep all my current work, but I can't seem to add it to 
> PythonPath / sys.path
> 
> When I try to import one of my modules I see
> 
 import My_Working_File
> Traceback (most recent call last):
>  File "", line 1, in 
>import My_Working_File
> ImportError: No module named 'My_Working_File'
> 
> I have tried adding my dir in registry to the existing PythonPath 
> 
> [HKEY_CURRENT_USER\Software\Python\PythonCore\3.4\PythonPath]
> @="D:\\Shades\\Tools\\Python\\Lib;D:\\Shades\\Tools\\Python\\DLLs"
> 
> that did not help, 
> 
> I tried adding PYTHONPATH as an enviramental variable, that also had no effect
> 
> (I did re-boot after these two tests)
> 
> If I go to the editor window and run (F5) any of my modules then I can 
> 
  RESTART 
 
 import My_Working_File
 
> 
> without error
> 
> I can also (from a fresh start) 
> 
 import sys
 sys.path.append(r'D:\Shades\Tools\Python\MyWork')
 print(sys.path)
> ['', 'D:\\Shades\\Tools\\Python\\Lib\\idlelib', 
> 'D:\\Shades\\Tools\\Python\\python34.zip', 'D:\\Shades\\Tools\\Python\\DLLs', 
> 'D:\\Shades\\Tools\\Python\\lib', 'D:\\Shades\\Tools\\Python', 
> 'D:\\Shades\\Tools\\Python\\lib\\site-packages', 
> 'D:\\Shades\\Tools\\Python\\MyWork']
 import My_Working_File
 
> 
> I don't really want to go this route every time I start work, and more to the 
> point I will need (to learn how) to add dir's to the path at times
> 
> I did search the net for an answer but only got what I had already tried
> 
> any pointers what I'm doing wrong (other than using windows '->) 

I take it you have business reasons to use an obsolete version python.
Where did you get your version of python from?

You seem to be doing the right thing with setting an environment variable.
Useless shades is an app that embeds python.

Try starting cmd.exe and using the set command to liat all of the environment.
Do you see your PYTHONPATH variable?
Does it contain what you expect?
If it does start python and check that sys.path has your folder in it.
Also check what is on os.environ dirctionary.

Barry
> 
> Grizz
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH vs Python Virtual Environment

[Dieter Maurer]

Sina Mobasheri wrote at 2022-2-4 15:55 +:
>it's not good title defiantly and I don't mean to compare apples and oranges
>
>when I start using python virtual environment it was because isolation 
>proposes and everyone say about its benefits in isolation and working with 
>different versions of the same package in different projects
>
>but recently I start using pip install --target  for 
>zipapp
> things, and then I use this pip's option (--target) and add its target folder 
>to PYTHONPATH and target folder's bin directory to PATH, so it's like virtual 
>environment to me
>
>I'm curious what is a problem with this approach (edges), what are other 
>benefits of the virtual environment that this way can't offer? most tutorials 
>talk about isolation and managing of packages versions but I think maybe it's 
>more than that maybe?

Usually, PYTHONPATH is global.
This can make a problem when you have different applications
which require different package versions.

Of course, you can use a wrapper for your application which locally
sets PYTHONPATH appropriately.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH when calling from ipython

[Cecil Westerhof]

Op Saturday 23 May 2015 18:09 CEST schreef Peter Otten:

 Cecil Westerhof wrote:

 Op Saturday 23 May 2015 15:25 CEST schreef Peter Otten:

 Cecil Westerhof wrote:

 Op Saturday 23 May 2015 11:12 CEST schreef Mark Lawrence:

 On 22/05/2015 06:20, Cecil Westerhof wrote:
 I am looking into using ipython instead of bash. But when I
 call a python program from ipython PYTHONPATH is not set. So
 pythonscripts that need a module through PYTHONPATH will not
 work.

 I could do something like:
 !PYTHONPATH=~/Python/PythonLibrary python2 …

 But I find that a little bit cumbersome. Is there a better way
 to do it?


 What makes you think this?  Have you tried:-

 import os
 os.environ['PYTHONPATH']
 'C:\\Users\\Mark\\Documents\\Cash\\Python;C:
 \\Users\\Mark\\Documents\\MyPython'

 That might be from the command line interpreter but it also
 works the same from iPython for me on Windows 8.1.

 That does not change anything. The modules are not found. Also
 not when using %run.


 That may be because ~ is not expanded.

 Try

 os.environ[PYTHONPATH] =
 os.path.expanduser(~/Python/PythonLibary)

 That is not the problem:
 os.environ['PYTHONPATH']
 gives:
 .:/home/cecil/Python'

 As I interpret it is that the very handy shell variable is not used
 in ipython.


 I can't confirm that finding. For test purposes I created
 foo/bar/hello.py. Then I verified that the hello.py module is not
 found when invoking the python3 interpreter from within ipython3.
 Once I update os.environ[PYTHONPATH] the module is successfully
 imported. The complete session:

I should have checked better. I think I found a bug that made it look
like PYTHONPATH does not work.

In bash I give:
echo $PYTHONPATH
this gives:
.:/home/cecil/Python/PythonLibrary

Then I start ipython3 and get/do the following:
Python 3.4.1 (default, May 23 2014, 17:48:28) [GCC]
Type copyright, credits or license for more information.

IPython 2.2.0 -- An enhanced Interactive Python.
? - Introduction and overview of IPython's features.
%quickref - Quick reference.
help  - Python's own help system.
object?   - Details about 'object', use 'object??' for extra details.

In [1]: import os

In [2]: os.environ['PYTHONPATH']
Out[2]: '.:/home/cecil/Python'

And PYTHONPATH has a different value. That is why my module is not
found.

When I set PYTHONPATH to the correct value, everything works as
expected:
In [3]: os.environ['PYTHONPATH'] = '.:/home/cecil/Python/PythonLibrary/'

In [4]: !python2 postOnTwitter.py --used
Citation has 50 saved messages of 126:
[6, 55, 43, 82, 28, 116, 2, 50, 100, 5, 0, 122, 75, 51, 121, 60, 114, 13, 
102, 78, 31, 107, 73, 109, 54, 119, 72, 90, 89, 113, 118, 41, 11, 27, 48, 77, 
19, 111, 62, 98, 110, 9, 10, 115, 63, 15, 53, 101, 94, 92]

Tips has 30 saved messages of 94:
[20, 37, 7, 59, 45, 49, 40, 87, 79, 78, 31, 14, 15, 25, 84, 18, 91, 53, 8, 
35, 80, 92, 34, 42, 74, 69, 64, 22, 86, 62]

That begs the question: what is the reason for the corruption of
PYTHONPATH?

I already answered it partly myself. When I change PYTHONPATH in bash
and call ipython3 again, it has the same value as before, so it does
not take its value from the calling bash as I would expect.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH when calling from ipython

[Cecil Westerhof]

Op Saturday 23 May 2015 20:13 CEST schreef Mark Lawrence:

 On 23/05/2015 18:30, Cecil Westerhof wrote:

 I should have checked better. I think I found a bug that made it
 look like PYTHONPATH does not work.

 In bash I give:
 echo $PYTHONPATH
 this gives:
 .:/home/cecil/Python/PythonLibrary

 Then I start ipython3 and get/do the following:
 Python 3.4.1 (default, May 23 2014, 17:48:28) [GCC]
 Type copyright, credits or license for more information.

 IPython 2.2.0 -- An enhanced Interactive Python.

 The latest iPython is 3.1.0.  Time to update?

Maybe. ;-)

Strange thing is that ipython (for python 2) uses 3.0.0. This is on
openSUSE 13.2. On Debian 8 both use 2.3.0.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH when calling from ipython

[Mark Lawrence]

On 22/05/2015 06:20, Cecil Westerhof wrote:

I am looking into using ipython instead of bash. But when I call a
python program from ipython PYTHONPATH is not set. So pythonscripts
that need a module through PYTHONPATH will not work.

I could do something like:
 !PYTHONPATH=~/Python/PythonLibrary python2 …

But I find that a little bit cumbersome. Is there a better way to do
it?



What makes you think this?  Have you tried:-

 import os
 os.environ['PYTHONPATH']
'C:\\Users\\Mark\\Documents\\Cash\\Python;C:\\Users\\Mark\\Documents\\MyPython'

That might be from the command line interpreter but it also works the 
same from iPython for me on Windows 8.1.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH when calling from ipython

[Peter Otten]

Cecil Westerhof wrote:

 Op Saturday 23 May 2015 11:12 CEST schreef Mark Lawrence:
 
 On 22/05/2015 06:20, Cecil Westerhof wrote:
 I am looking into using ipython instead of bash. But when I call a
 python program from ipython PYTHONPATH is not set. So pythonscripts
 that need a module through PYTHONPATH will not work.

 I could do something like:
 !PYTHONPATH=~/Python/PythonLibrary python2 …

 But I find that a little bit cumbersome. Is there a better way to
 do it?


 What makes you think this?  Have you tried:-

 import os
 os.environ['PYTHONPATH']
 'C:\\Users\\Mark\\Documents\\Cash\\Python;C:
\\Users\\Mark\\Documents\\MyPython'

 That might be from the command line interpreter but it also works
 the same from iPython for me on Windows 8.1.
 
 That does not change anything. The modules are not found. Also not
 when using %run.
 

That may be because ~ is not expanded.

Try

os.environ[PYTHONPATH] = os.path.expanduser(~/Python/PythonLibary)


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH when calling from ipython

[Cecil Westerhof]

Op Saturday 23 May 2015 11:12 CEST schreef Mark Lawrence:

 On 22/05/2015 06:20, Cecil Westerhof wrote:
 I am looking into using ipython instead of bash. But when I call a
 python program from ipython PYTHONPATH is not set. So pythonscripts
 that need a module through PYTHONPATH will not work.

 I could do something like:
 !PYTHONPATH=~/Python/PythonLibrary python2 …

 But I find that a little bit cumbersome. Is there a better way to
 do it?


 What makes you think this?  Have you tried:-

 import os
 os.environ['PYTHONPATH']
 'C:\\Users\\Mark\\Documents\\Cash\\Python;C:\\Users\\Mark\\Documents\\MyPython'

 That might be from the command line interpreter but it also works
 the same from iPython for me on Windows 8.1.

That does not change anything. The modules are not found. Also not
when using %run.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH when calling from ipython

[Cecil Westerhof]

Op Saturday 23 May 2015 15:25 CEST schreef Peter Otten:

 Cecil Westerhof wrote:

 Op Saturday 23 May 2015 11:12 CEST schreef Mark Lawrence:

 On 22/05/2015 06:20, Cecil Westerhof wrote:
 I am looking into using ipython instead of bash. But when I call
 a python program from ipython PYTHONPATH is not set. So
 pythonscripts that need a module through PYTHONPATH will not
 work.

 I could do something like:
 !PYTHONPATH=~/Python/PythonLibrary python2 …

 But I find that a little bit cumbersome. Is there a better way to
 do it?


 What makes you think this?  Have you tried:-

 import os
 os.environ['PYTHONPATH']
 'C:\\Users\\Mark\\Documents\\Cash\\Python;C:
 \\Users\\Mark\\Documents\\MyPython'

 That might be from the command line interpreter but it also works
 the same from iPython for me on Windows 8.1.

 That does not change anything. The modules are not found. Also not
 when using %run.


 That may be because ~ is not expanded.

 Try

 os.environ[PYTHONPATH] =
 os.path.expanduser(~/Python/PythonLibary)

That is not the problem:
os.environ['PYTHONPATH']
gives:
.:/home/cecil/Python'

As I interpret it is that the very handy shell variable is not used in ipython.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH when calling from ipython

[Laura Creighton]

In a message of Sat, 23 May 2015 16:08:00 +0200, Cecil Westerhof writes:
That is not the problem:
os.environ['PYTHONPATH']
gives:
.:/home/cecil/Python'

As I interpret it is that the very handy shell variable is not used in ipython.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

It's used around here.  But we all have to do:
export PYTHONPATH=${PYTHONPATH}:/usr/local/ipython/lib/python
in our .bashrc files -- or whatever you do if you don't use bash
to get things to work with ipython.

Is your problem that you are not getting one particular directory
loaded, or can you not find any modules at all?

Laura
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH when calling from ipython

[Cecil Westerhof]

Op Saturday 23 May 2015 17:00 CEST schreef Laura Creighton:

 In a message of Sat, 23 May 2015 16:08:00 +0200, Cecil Westerhof
 writes:
 That is not the problem:
 os.environ['PYTHONPATH']
 gives:
 .:/home/cecil/Python'

 As I interpret it is that the very handy shell variable is not used
 in ipython.

 -- 
 Cecil Westerhof
 Senior Software Engineer
 LinkedIn: http://www.linkedin.com/in/cecilwesterhof

 It's used around here.  But we all have to do:
 export PYTHONPATH=${PYTHONPATH}:/usr/local/ipython/lib/python
 in our .bashrc files -- or whatever you do if you don't use bash
 to get things to work with ipython.

But I would like to do the same in ipython. Otherwise it is not really
a good idea to switch from bash to ipython.


 Is your problem that you are not getting one particular directory
 loaded, or can you not find any modules at all?

Normal modules are loaded. Only the ones that are found trough
PYTHONPATH are not found.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH when calling from ipython

[Peter Otten]

Cecil Westerhof wrote:

 Op Saturday 23 May 2015 15:25 CEST schreef Peter Otten:
 
 Cecil Westerhof wrote:

 Op Saturday 23 May 2015 11:12 CEST schreef Mark Lawrence:

 On 22/05/2015 06:20, Cecil Westerhof wrote:
 I am looking into using ipython instead of bash. But when I call
 a python program from ipython PYTHONPATH is not set. So
 pythonscripts that need a module through PYTHONPATH will not
 work.

 I could do something like:
 !PYTHONPATH=~/Python/PythonLibrary python2 …

 But I find that a little bit cumbersome. Is there a better way to
 do it?


 What makes you think this?  Have you tried:-

 import os
 os.environ['PYTHONPATH']
 'C:\\Users\\Mark\\Documents\\Cash\\Python;C:
 \\Users\\Mark\\Documents\\MyPython'

 That might be from the command line interpreter but it also works
 the same from iPython for me on Windows 8.1.

 That does not change anything. The modules are not found. Also not
 when using %run.


 That may be because ~ is not expanded.

 Try

 os.environ[PYTHONPATH] =
 os.path.expanduser(~/Python/PythonLibary)
 
 That is not the problem:
 os.environ['PYTHONPATH']
 gives:
 .:/home/cecil/Python'
 
 As I interpret it is that the very handy shell variable is not used in
 ipython.
 

I can't confirm that finding. For test purposes I created foo/bar/hello.py.
Then I verified that the hello.py module is not found when invoking the 
python3 interpreter from within ipython3.
Once I update os.environ[PYTHONPATH] the module is successfully imported.
The complete session:

$ mkdir -p foo/bar
$ echo 'print(hello from foo/bar)'  foo/bar/hello.py
$ ipython3
Python 3.4.0 (default, Apr 11 2014, 13:05:11) 
Type copyright, credits or license for more information.

IPython 1.2.1 -- An enhanced Interactive Python.
? - Introduction and overview of IPython's features.
%quickref - Quick reference.
help  - Python's own help system.
object?   - Details about 'object', use 'object??' for extra details.

In [1]: import hello.py
---
ImportError   Traceback (most recent call last)
ipython-input-1-d9db4361d25a in module()
 1 import hello.py

ImportError: No module named 'hello'

In [2]: import os

In [3]: !python3 -c 'import hello'
Traceback (most recent call last):
  File string, line 1, in module
ImportError: No module named 'hello'

In [4]: os.environ[PYTHONPATH] = foo/bar

In [5]: !python3 -c 'import hello'
hello from foo/bar


If that's not what you want please explain in similar detail what you want 
to achieve and what you actually tried. Thank you.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH when calling from ipython

[Mark Lawrence]

On 23/05/2015 18:30, Cecil Westerhof wrote:


I should have checked better. I think I found a bug that made it look
like PYTHONPATH does not work.

In bash I give:
 echo $PYTHONPATH
this gives:
 .:/home/cecil/Python/PythonLibrary

Then I start ipython3 and get/do the following:
 Python 3.4.1 (default, May 23 2014, 17:48:28) [GCC]
 Type copyright, credits or license for more information.

 IPython 2.2.0 -- An enhanced Interactive Python.


The latest iPython is 3.1.0.  Time to update?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH when calling from ipython

[Cecil Westerhof]

Op Saturday 23 May 2015 19:30 CEST schreef Cecil Westerhof:

 I should have checked better. I think I found a bug that made it
 look like PYTHONPATH does not work.

 In bash I give:
 echo $PYTHONPATH
 this gives:
 .:/home/cecil/Python/PythonLibrary

 Then I start ipython3 and get/do the following:
 Python 3.4.1 (default, May 23 2014, 17:48:28) [GCC]
 Type copyright, credits or license for more information.

 IPython 2.2.0 -- An enhanced Interactive Python. ? - Introduction
 and overview of IPython's features. %quickref - Quick reference.
 help - Python's own help system. object? - Details about 'object',
 use 'object??' for extra details.

 In [1]: import os

 In [2]: os.environ['PYTHONPATH']
 Out[2]: '.:/home/cecil/Python'

 And PYTHONPATH has a different value. That is why my module is not
 found.

 When I set PYTHONPATH to the correct value, everything works as
 expected: In [3]: os.environ['PYTHONPATH'] =
 '.:/home/cecil/Python/PythonLibrary/'

 In [4]: !python2 postOnTwitter.py --used Citation has 50 saved
 messages of 126: [6, 55, 43, 82, 28, 116, 2, 50, 100, 5, 0, 122, 75,
 51, 121, 60, 114, 13, 102, 78, 31, 107, 73, 109, 54, 119, 72, 90,
 89, 113, 118, 41, 11, 27, 48, 77, 19, 111, 62, 98, 110, 9, 10, 115,
 63, 15, 53, 101, 94, 92]

 Tips has 30 saved messages of 94:
 [20, 37, 7, 59, 45, 49, 40, 87, 79, 78, 31, 14, 15, 25, 84, 18, 91,
 53, 8, 35, 80, 92, 34, 42, 74, 69, 64, 22, 86, 62]

 That begs the question: what is the reason for the corruption of
 PYTHONPATH?

 I already answered it partly myself. When I change PYTHONPATH in
 bash and call ipython3 again, it has the same value as before, so it
 does not take its value from the calling bash as I would expect.

Well it was my fault again. Linux can run very long before you need to
restart it. I work with screen. Before PYTHONPATH was
.:/home/cecil/Python, but later on I changed it to
.:/home/cecil/Python/PythonLibrary. When starting a new shell, the
bash shell had the right value. But when starting ipython it got the
old value. Importing os is not even necessary:
Python 3.4.1 (default, May 23 2014, 17:48:28) [GCC]
Type copyright, credits or license for more information.

IPython 2.2.0 -- An enhanced Interactive Python.
? - Introduction and overview of IPython's features.
%quickref - Quick reference.
help  - Python's own help system.
object?   - Details about 'object', use 'object??' for extra details.

In [1]: !python2 postOnTwitter.py --used
python2: can't open file 'postOnTwitter.py': [Errno 2] No such file or 
directory

In [2]: !python2 postOnTwitter.py --used
Citation has 50 saved messages of 126:
[6, 55, 43, 82, 28, 116, 2, 50, 100, 5, 0, 122, 75, 51, 121, 60, 114, 13, 
102, 78, 31, 107, 73, 109, 54, 119, 72, 90, 89, 113, 118, 41, 11, 27, 48, 77, 
19, 111, 62, 98, 110, 9, 10, 115, 63, 15, 53, 101, 94, 92]

Tips has 30 saved messages of 94:
[20, 37, 7, 59, 45, 49, 40, 87, 79, 78, 31, 14, 15, 25, 84, 18, 91, 53, 8, 
35, 80, 92, 34, 42, 74, 69, 64, 22, 86, 62]


Feeling a bit silly at the moment. :-(


By the way I use python2 because the program uses a library that does
not work with python3.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH and module names

[SpaghettiToastBook .]

Relative imports only work with the from ... import ... form.

— SpaghettiToastBook


On Mon, Jul 1, 2013 at 3:54 PM, Tobiah t...@tobiah.org wrote:
 Are you familiar with absolute and relative imports:
 http://docs.python.org/release/2.5/whatsnew/pep-328.html


 Doesn't seem to work:

 Python 2.7.3 (default, May 10 2012, 13:31:18)
 [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu4)] on linux2
 Type help, copyright, credits or license for more information.
 from __future__ import absolute_import
 import .format
   File stdin, line 1
 import .format
^
 SyntaxError: invalid syntax


 --
 http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH and module names

[rusi]

On Monday, July 1, 2013 11:59:35 PM UTC+5:30, Tobiah wrote:
 So today, I created a file called 'formatter.py',
 and my program broke.  It turned out that I was
 also import 'gluon' from web2py, which in turn,
 somewhere, imported the regular python formatter.py
 with which I was not familiar.
 
 So the question is: Does one simply always have
 to be knowledgeable about existing python library
 names, or is having '.' in the python path just
 a bad idea?  Is there a way, not having '.' in
 the path to explicitly specify the current directory?
 Something analogous to import ./foo ?

Are you familiar with absolute and relative imports:
http://docs.python.org/release/2.5/whatsnew/pep-328.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH and module names

[Tobiah]

Are you familiar with absolute and relative imports:
http://docs.python.org/release/2.5/whatsnew/pep-328.html


Doesn't seem to work:

Python 2.7.3 (default, May 10 2012, 13:31:18)
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu4)] on linux2
Type help, copyright, credits or license for more information.
 from __future__ import absolute_import
 import .format
  File stdin, line 1
import .format
   ^
SyntaxError: invalid syntax


--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH and module names

[rusi]

On Tuesday, July 2, 2013 1:24:30 AM UTC+5:30, Tobiah wrote:
  Are you familiar with absolute and relative imports:
  http://docs.python.org/release/2.5/whatsnew/pep-328.html
 
 Doesn't seem to work:
 Python 2.7.3 (default, May 10 2012, 13:31:18)
 [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu4)] on linux2
 Type help, copyright, credits or license for more information.
   from __future__ import absolute_import
   import .format
File stdin, line 1
  import .format
 ^
 SyntaxError: invalid syntax
  

1. My reading of 
http://www.python.org/dev/peps/pep-0328/
is that this only works for from statements not import statements.
[See the section called Guido's decision]

2. The __future__ is not necessary in python 2.7
[Not necessary or not allowed I not know :-) ]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH and module names

[Steven D'Aprano]

On Mon, 01 Jul 2013 14:38:50 -0700, rusi wrote:

 On Tuesday, July 2, 2013 1:24:30 AM UTC+5:30, Tobiah wrote:
  Are you familiar with absolute and relative imports:
  http://docs.python.org/release/2.5/whatsnew/pep-328.html
 
 Doesn't seem to work:
 Python 2.7.3 (default, May 10 2012, 13:31:18) [GCC 4.2.4 (Ubuntu
 4.2.4-1ubuntu4)] on linux2 Type help, copyright, credits or
 license for more information.
   from __future__ import absolute_import import .format
File stdin, line 1
  import .format
 ^
 SyntaxError: invalid syntax
  
  
 1. My reading of
 http://www.python.org/dev/peps/pep-0328/ is that this only works for
 from statements not import statements. [See the section called Guido's
 decision]


Correct. This would have to be written as:

from . import format


but note that this only work in a package, not from some arbitrary module 
inside a directory.


 
 2. The __future__ is not necessary in python 2.7 [Not necessary or not
 allowed I not know :-) ]

Not necessary.

__future__ statements are guaranteed to work in all future versions, in 
the sense that once a __future__ feature is added, it will never be 
removed. So Python has had nested scopes since version 2.2 (by memory), 
but:

from __future__ import nested_scopes

still is allowed in Python 3.3, even though it has been a no-op since 2.2 
or 2.3.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH and module names

[Fábio Santos]

On 1 Jul 2013 20:58, Tobiah t...@tobiah.org wrote:

 Are you familiar with absolute and relative imports:
 http://docs.python.org/release/2.5/whatsnew/pep-328.html


 Doesn't seem to work:

 Python 2.7.3 (default, May 10 2012, 13:31:18)
 [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu4)] on linux2
 Type help, copyright, credits or license for more information.
  from __future__ import absolute_import
  import .format
   File stdin, line 1
 import .format
^
 SyntaxError: invalid syntax
 

Have you tried

from . import format

?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH and module names

[Lele Gaifax]

Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:

 On Mon, 01 Jul 2013 14:38:50 -0700, rusi wrote:
 2. The __future__ is not necessary in python 2.7 [Not necessary or not
 allowed I not know :-) ]

 Not necessary.

IIRC that it is needed, to solve the OP problem: one thing is the
syntax, which under Python 2.7 is enabled by default, another thing is
the behaviour, that is whether the interpreter will give priority to the
sys.path.

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH: dev and prod

[jacopo]

On Wednesday, June 12, 2013 5:10:05 PM UTC+1, rusi wrote:
 On Jun 12, 6:29 pm, jacopo jacopo.pe...@gmail.com wrote:
 
   1. How you run -- 'launch' -- the code -- from py and from prod
 
 
 
  when I have to test I use python any_script.py  but in production there 
  is a c++ program that is able to wrap and run python code (the technical 
  details are a bit beyond my knowledge)
 
 
 
   2. What error you get
 
 
 
  when I run as python any_script.py I get
 
  ValueError: Attempted relative import in non-package
 
  I have found this 
  explanation:http://stackoverflow.com/questions/11536764/attempted-relative-import...
 
  So I have added at the top of my module:
 
 
 
  if __name__==__main__ and __package__ is None:
 
       __package__=myscripts
 
  from ..mylib import MyClass
 
 
 
  and I get the error:
 
  SystemError: Parent module 'mylib' not loaded, canno perform relative import
 
 
 
   3. Did you try bundling your modules into a package? What problem
 
   happened?
 
 
 
  What does it mean? what does build mean in this contest? I am not 
  compiling, I just write the .py files.
 
 
 
 I mean use a python package to wrap the modules.
 
 Roughly that means have a file named __init__.py in the root of your
 
 modules directory.
 
 For the details see http://docs.python.org/2/tutorial/modules.html#packages
 
 
 
 More intricacies I dont know. Hopefully someone who knows better can
 
 answer

thank you Rusi for your help
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH: dev and prod

[jacopo]

this idea seemed perfect but it turned out that you have to execute the module 
as a package (python -m scripts.myscript) otherwise I get an error on the 
relative import. 
Unfortunately I am working in a team and I do not have control on how the 
module is launched.


On Tuesday, June 11, 2013 6:14:43 PM UTC+1, rusi wrote:
 On Jun 11, 9:28 pm, jacopo jacopo.pe...@gmail.com wrote:
 
  I am developing my code in the path:
 
  /py/myscripts
 
  /py/mylib
 
  In order to import mylib, I need to add /py/mylib to PYTHONPATH.
 
 
 
  Now I want to save a snapshot of the current code in the production 
  directory, I will copy all in:
 
  /prod/myscripts
 
  /prod/mylib
 
 
 
  The problem now is that when I execute /prod/myscripts/any_script.py, every 
  import will look at PYTHONPATH and therefore it will load the modules 
  from /py/mylib. On the contrary I want to load it from /prod/mylib.
 
 
 
  Is there an elegant way to cope with this?
 
 
 
  thanks, Jacopo
 
 
 
 I-think
 
 Use explicit (dot-based) relative imports
 
 http://docs.python.org/release/2.5/whatsnew/pep-328.html
 
 Avoid using PYTHONPATH
 
 /I-think

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH: dev and prod

[jacopo]

this idea seemed perfect but it turned out that you have to execute the module 
as a package (python -m py.myscripts.any_script) otherwise I get an error on 
the relative import. 
Unfortunately I am working in a team and I do not have control on how the 
module is launched. 

On Tuesday, June 11, 2013 6:14:43 PM UTC+1, rusi wrote:
 On Jun 11, 9:28 pm, jacopo jacopo.pe...@gmail.com wrote:
 
  I am developing my code in the path:
 
  /py/myscripts
 
  /py/mylib
 
  In order to import mylib, I need to add /py/mylib to PYTHONPATH.
 
 
 
  Now I want to save a snapshot of the current code in the production 
  directory, I will copy all in:
 
  /prod/myscripts
 
  /prod/mylib
 
 
 
  The problem now is that when I execute /prod/myscripts/any_script.py, every 
  import will look at PYTHONPATH and therefore it will load the modules 
  from /py/mylib. On the contrary I want to load it from /prod/mylib.
 
 
 
  Is there an elegant way to cope with this?
 
 
 
  thanks, Jacopo
 
 
 
 I-think
 
 Use explicit (dot-based) relative imports
 
 http://docs.python.org/release/2.5/whatsnew/pep-328.html
 
 Avoid using PYTHONPATH
 
 /I-think
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH: dev and prod

[rusi]

On Jun 12, 4:10 pm, jacopo jacopo.pe...@gmail.com wrote:
 this idea seemed perfect but it turned out that you have to execute the 
 module as a package
 (python -m py.myscripts.any_script) otherwise I get an error on the relative 
 import.
 Unfortunately I am working in a team and I do not have control on how the 
 module is launched.

You need to give more data:

1. How you run -- 'launch' -- the code -- from py and from prod
2. What error you get
3. Did you try bundling your modules into a package? What problem
happened?

If PYTHONPATH does not work for you you can look at path-configuration-
files (.pth) files
http://docs.python.org/2/library/site.html [Ive not used them myself]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH: dev and prod

[jacopo]

 1. How you run -- 'launch' -- the code -- from py and from prod
when I have to test I use python any_script.py  but in production there is a 
c++ program that is able to wrap and run python code (the technical details are 
a bit beyond my knowledge)
 
 2. What error you get
when I run as python any_script.py I get
ValueError: Attempted relative import in non-package
I have found this explanation:
http://stackoverflow.com/questions/11536764/attempted-relative-import-in-non-package-even-with-init-py
So I have added at the top of my module:

if __name__==__main__ and __package__ is None:
 __package__=myscripts
from ..mylib import MyClass

and I get the error:
SystemError: Parent module 'mylib' not loaded, canno perform relative import

 
 3. Did you try bundling your modules into a package? What problem
 happened?
What does it mean? what does build mean in this contest? I am not compiling, I 
just write the .py files.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH: dev and prod

[rusi]

On Jun 12, 6:29 pm, jacopo jacopo.pe...@gmail.com wrote:
  1. How you run -- 'launch' -- the code -- from py and from prod

 when I have to test I use python any_script.py  but in production there is 
 a c++ program that is able to wrap and run python code (the technical details 
 are a bit beyond my knowledge)

  2. What error you get

 when I run as python any_script.py I get
 ValueError: Attempted relative import in non-package
 I have found this 
 explanation:http://stackoverflow.com/questions/11536764/attempted-relative-import...
 So I have added at the top of my module:

 if __name__==__main__ and __package__ is None:
      __package__=myscripts
 from ..mylib import MyClass

 and I get the error:
 SystemError: Parent module 'mylib' not loaded, canno perform relative import

  3. Did you try bundling your modules into a package? What problem
  happened?

 What does it mean? what does build mean in this contest? I am not compiling, 
 I just write the .py files.

I mean use a python package to wrap the modules.
Roughly that means have a file named __init__.py in the root of your
modules directory.
For the details see http://docs.python.org/2/tutorial/modules.html#packages

More intricacies I dont know. Hopefully someone who knows better can
answer
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH: dev and prod

[rusi]

On Jun 11, 9:28 pm, jacopo jacopo.pe...@gmail.com wrote:
 I am developing my code in the path:
 /py/myscripts
 /py/mylib
 In order to import mylib, I need to add /py/mylib to PYTHONPATH.

 Now I want to save a snapshot of the current code in the production 
 directory, I will copy all in:
 /prod/myscripts
 /prod/mylib

 The problem now is that when I execute /prod/myscripts/any_script.py, every 
 import will look at PYTHONPATH and therefore it will load the modules from 
 /py/mylib. On the contrary I want to load it from /prod/mylib.

 Is there an elegant way to cope with this?

 thanks, Jacopo

I-think
Use explicit (dot-based) relative imports
http://docs.python.org/release/2.5/whatsnew/pep-328.html
Avoid using PYTHONPATH
/I-think
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH

[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.
--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH

[harrismh777]

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

--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH

[Steven D'Aprano]

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH

[harrismh777]

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


--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH

[Algis Kabaila]

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH

[jmfauth]

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH

[Algis Kabaila]

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH

[Chris Rebert]

On Fri, Apr 15, 2011 at 1:33 AM, Algis Kabaila akaba...@pcug.org.au wrote:
 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?

It is an environment variable:
http://en.wikipedia.org/wiki/Environment_variable

Alternatively, you can use a .pth file to add directories to the
module search path:
http://docs.python.org/library/site.html

Cheers,
Chris
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH

[Gabriel Genellina]

En Fri, 15 Apr 2011 05:33:18 -0300, Algis Kabaila akaba...@pcug.org.au  
escribió:



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?


PYTHONPATH is an environment variable, you set it the same way as any  
other, the details depend on the operating system/shell you're currently  
using.


But - why do you think you need to set PYTHONPATH? Don't do that. Use the  
standard places to put your library modules and packages, like  
site-packages (where third-party libraries are installed by default). From  
Python 2.6+ the search path includes per-user directories like  
~/.local/lib/python2.6/site-packages and  
%APPDATA%\Python\Python26\site-packages (see PEP370 [1] for details) so  
you don't even have to mess with the Python installation directories.



[1] http://www.python.org/dev/peps/pep-0370/

--
Gabriel Genellina

--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH

[Algis Kabaila]

On Friday 15 April 2011 19:21:12 Chris Rebert wrote:
 On Fri, Apr 15, 2011 at 1:33 AM, Algis Kabaila 
akaba...@pcug.org.au wrote:
  Hi,
  
snip..
 It is an environment variable:
 http://en.wikipedia.org/wiki/Environment_variable
 
 Alternatively, you can use a .pth file to add directories to
 the module search path:
 http://docs.python.org/library/site.html
 
 Cheers,
 Chris

From Gabriel Genellina:
 akaba...@pcug.org.au
 escribió:
  An elementary question that is bugging me, regarding
 
 PYTHONPATH is an environment variable, you set it the same
 way as any other, the details depend on the operating
 system/shell you're currently using.
 
 But - why do you think you need to set PYTHONPATH? Don't do
 that. Use the standard places to put your library modules
 and packages, like site-packages (where third-party
 libraries are installed by default). From Python 2.6+ the
 search path includes per-user directories like
 ~/.local/lib/python2.6/site-packages and
 %APPDATA%\Python\Python26\site-packages (see PEP370 [1] for
 details) so you don't even have to mess with the Python
 installation directories.
 
 
 [1] http://www.python.org/dev/peps/pep-0370/

Thank you Gabriel and Thank you Chris, for your valuable advice 
and equally valuable set of references.  Greatly appreciated!  

To answer the question of why consider a local sandbox to test 
various versions of a set of programs downloaded from the net.  
It is very handy to be able to change the standard behaviour 
to a localised users standard.  Even more important, of 
course, is to know what standards there are.

Thank you for your prompt and valuable assistance,
OldAl.


-- 
Algis
http://akabaila.pcug.org.au/StructuralAnalysis.pdf
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH

[harrismh777]

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




--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH and eggs

[geoffbache]

On Mar 4, 3:24 am, David Cournapeau courn...@gmail.com wrote:
 On Wed, Mar 3, 2010 at 7:14 PM, geoffbache geoff.ba...@jeppesen.com wrote:
  Unfortunately, the location from PYTHONPATH ends up after the eggs in
  sys.path so I can't persuade Python to import my version. The only way
  I've found to fix it is to copy the main script and manually hack
  sys.path at the start of it which isn't really very nice. I wonder if
  there is any better way as I can't be the first person to want to do
  this, surely?

 One way is to never install things as eggs: I have a script
 hard_install which forces things to always install with
 --single-externally-managed blablabla. This has worked very well for
 me, but may not always be applicable (in particular if you are on a
 platform where building things from sources is difficult).

Thanks for the tips. Is your script generic at all? I wonder if you'd
be prepared to share it?

Figuring out virtualenv would also be an option, as would figuring out
how to build my own egg, but both these solutions feel like overkill
to me just to enable a small bit of tweaking.

/Geoff
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH and eggs

[Jonathan Gardner]

On Wed, Mar 3, 2010 at 2:14 AM, geoffbache geoff.ba...@jeppesen.com wrote:

 I have a very simple problem that seems to have no simple solution.

 I have a module which is installed centrally and lives in a Python
 egg. I have experimented with some minor changes to it and would like
 to set my PYTHONPATH to pick up my local copy of it, but don't want to
 have to figure out how to build my own version of the egg if
 possible.

 Unfortunately, the location from PYTHONPATH ends up after the eggs in
 sys.path so I can't persuade Python to import my version. The only way
 I've found to fix it is to copy the main script and manually hack
 sys.path at the start of it which isn't really very nice. I wonder if
 there is any better way as I can't be the first person to want to do
 this, surely?

 I've seen this issue has been discussed elsewhere and flagged as a
 problem (e.g.
 http://mail.python.org/pipermail/distutils-sig/2009-January/010755.html)

 but I've been unable to find any suggestions for workarounds or
 indications whether this will be/has been fixed.


Sounds like you might need to use virtualenv to setup python
environments that you can control.

-- 
Jonathan Gardner
jgard...@jonathangardner.net
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH and eggs

[David Cournapeau]

On Wed, Mar 3, 2010 at 7:14 PM, geoffbache geoff.ba...@jeppesen.com wrote:

 Unfortunately, the location from PYTHONPATH ends up after the eggs in
 sys.path so I can't persuade Python to import my version. The only way
 I've found to fix it is to copy the main script and manually hack
 sys.path at the start of it which isn't really very nice. I wonder if
 there is any better way as I can't be the first person to want to do
 this, surely?

One way is to never install things as eggs: I have a script
hard_install which forces things to always install with
--single-externally-managed blablabla. This has worked very well for
me, but may not always be applicable (in particular if you are on a
platform where building things from sources is difficult).

cheers,

David
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pythonpath

[刘宇辉]

Sorry for my stupid question if i have to load module from a folder ihave
to append it to the sys path the folder?
ex:
if my  folder module is  /home/lucak904/Scrivania/Luca/enigma2
i do this :
import sys
sys.path.append('/home/lucak904/Scrivania/Luca/enigma2')
If this is correct why when i write:
form enigma2 import *
i get no module named enigma2

is  the folder module  /home/lucak904/Scrivania/Luca/enigma2.py?   i think
the extension  is necessary .

-- 
wolf python london
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pythonpath

[Albert Hopkins]

On Mon, 2010-03-01 at 02:48 -0800, luca72 wrote:
 Sorry for my stupid question if i have to load module from a folder i
 have to append it to the sys path the folder?
 ex:
 if my  folder module is  /home/lucak904/Scrivania/Luca/enigma2
 i do this :
 import sys
 sys.path.append('/home/lucak904/Scrivania/Luca/enigma2')
 If this is correct why when i write:
 form enigma2 import *
 i get no module named enigma2

There are two reasons for this:

 1. enigma2 is not in your namespace.  What's inside enigma is.  For
example, you can't say from site-packages import *  because
Python doesn't look at site-packages. It looks at what's
inside site-packages.  If you wanted enigma2 to be in your
namespace, you should add /home/lucak904/Scrivania/Luca to your
system path.
 2. Even if you did above, it may not work because enigma2 is a
directory. Remember from x import * only works for modules and
packages, so if you want enigma2 to be a package, remember to
add an (empty) __init__.py to the directory.

Hope this helps.
-a


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pythonpath

[Dave Angel]

Ray Holt wrote:

Is there a way to make python point to a different directory for modules. I
don't like to keep my modules in the program directory, but I can't figure
out from the shell how to get the program to look in another directory. I am
using XP Pro as an operating system and python2.6

  
There are a few standard places that Python already looks for module 
imports.  To see what they are on your system, you could simply look at 
sys.path.


import sys
for path in sys.path:
print path

In particular, you probably want to use the directory under appdata:

C:\Documents and Settings\\Application 
Data\Python\Python26\site-packages



where  is your user-name.

DaveA

--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH issue with sibling package names

[Diez B. Roggisch]

Stuart Moffatt wrote:

 Environment: Eclipse 3.4.2, Windows XP Pro SP2, Pydev 1.4.4, python
 2.6
 
 When I work in eclipse with java, I like to break up my client and
 server packages, like this:
 
 client-project/src/org/me/client
 
 server-project/src/org/me/api
 server-project/src/org/me/dao
 server-project/src/org/me/entity
 server-project/src/org/me/etc
 
 Then, when I need to call API code from the client, I make sure the
 API src is on the path.
 
 I am trying setup pydev projects to do the same thing, but running
 into an ImportError because my client code can't see the server src,
 even though it is on the path.
 
 Specifically, I am trying to import an entity from the server code
 into the client, like this:
 
from org.me.entity import MyEntity
 
 If I do this from any module in the server project it is fine (because
 the src path is in the same eclipse project). But if I do it from
 anywhere in the client code I get the ImportError
 
 From what I can tell, python asks for the closest module path, which
 is the current project. It finds org.me, but there is only the client
 sub-package. The org.me.entity sibling is in another eclipse project,
 but even though that path is on the PYTHONPATH, python stopped looking
 after it found a similarly named parent package.
 
 Is there a trusted way to make sure python looks through all paths for
 sibling packages? Can I load 'org.me.client' from one path in
 PYTHONPATH and 'org.me.*' from another path in PYTHONPATH? I imagine
 if I try to force python to load the second package first that the
 same thing will happen in reverse.

The solution you are searching for is called namespace packages, and you
can read more about it here:

  http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages


Do yourself a favor though, and don't use those several-steps-namespaces.
This is Python, not Java - two levels at *most*, normally a
project-namespace should be enough.

Diez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH issue with sibling package names

[Stuart Moffatt]

On Sep 10, 10:12 am, Diez B. Roggisch de...@nospam.web.de wrote:
 Stuart Moffatt wrote:
  Environment: Eclipse 3.4.2, Windows XP Pro SP2, Pydev 1.4.4, python
  2.6

  When I work in eclipse with java, I like to break up my client and
  server packages, like this:

  client-project/src/org/me/client

  server-project/src/org/me/api
  server-project/src/org/me/dao
  server-project/src/org/me/entity
  server-project/src/org/me/etc

  Then, when I need to call API code from the client, I make sure the
  API src is on the path.

  I am trying setup pydev projects to do the same thing, but running
  into an ImportError because my client code can't see the server src,
  even though it is on the path.

  Specifically, I am trying to import an entity from the server code
  into the client, like this:

     from org.me.entity import MyEntity

  If I do this from any module in the server project it is fine (because
  the src path is in the same eclipse project). But if I do it from
  anywhere in the client code I get the ImportError

  From what I can tell, python asks for the closest module path, which
  is the current project. It finds org.me, but there is only the client
  sub-package. The org.me.entity sibling is in another eclipse project,
  but even though that path is on the PYTHONPATH, python stopped looking
  after it found a similarly named parent package.

  Is there a trusted way to make sure python looks through all paths for
  sibling packages? Can I load 'org.me.client' from one path in
  PYTHONPATH and 'org.me.*' from another path in PYTHONPATH? I imagine
  if I try to force python to load the second package first that the
  same thing will happen in reverse.

 The solution you are searching for is called namespace packages, and you
 can read more about it here:

  http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages

 Do yourself a favor though, and don't use those several-steps-namespaces.
 This is Python, not Java - two levels at *most*, normally a
 project-namespace should be enough.

 Diez


Diez,

Thanks for the tips re: namespace packages. Yeah, I know this is
python, but for very large projects (or multiple projects for very
large clients) it is just more flexible to stick to the reverse-dot
java notation of domain.organization.project.namespace.

All I had to do was make sure that top- and mid-level folders had an
__init__.py with this line:

__import__('pkg_resources').declare_namespace(__name__)

in it (and nothing else).

So, for my example, I had:

client-project/src/org/__init__.py
client-project/src/org/me/__init__.py
server-project/src/org/__init__.py
server-project/src/org/me/__init__.py

...all with the special namespace declaration line above.

Note that the lowest level folders in the package:

client-project/src/org/me/client
server-project/src/org/me/api
server-project/src/org/me/etc

...all have __init__.py files with actual module code, and therefore
do NOT have the namespace declaration line.

To expose the server code (org.me.api, org.me.dao, etc) I have a
setup.py in the server-project/src folder with:

from setuptools import setup
setup(name='myserver',
version='1.0',
namespace_packages = ['org','org.me'],
packages=['org.me.api','org.me.dao','org.me.entity'],
)

A similar setup.py can be created for the client library too. Notice
that the setup has every level (except the last) in the
namespace_packages list argument. This is how it walks down the tree
and builds the namespace properly.

With this setup file I can make an .egg or .zip distribution using:

  cd server-project/src
  python setup.py bdist

  or

  python setup.py bdist_egg

For my dev environment in eclipse I also wanted the convenience of
editing server code AND have the latest code on the path for my client
project (without rebuilding a dist). To do this I just:

  cd server-project/src
  python setup.py develop

...which puts a symlink (even does it properly in Windows) in my
python/lib/site-packages folder. Now in my client code I can do a
regular import, even though the code lives in another project, and
though portions of the code base are at different PYTHONPATHs:

  from org.me.entity import MyEntity # from server-project/src
  from org.me.api import MyAPI # from server-project/src
  from org.me.client import MyClient # from client-project/src

When my code is complete, the myserver-1.0-py2.6.egg and myclient-1.0-
py2.6.egg can be included in other python modules by loading compiled
source from inside the egg with:

  from pkg_resources import require
  require(myserver=1.0)
  require(myclient=1.0)

and then:

  from org.me.entity import MyEntity # from compiled code in
myserver-1.0-py2.6.egg
  from org.me.api import MyAPI # from compiled code in myserver-1.0-
py2.6.egg
  from org.me.client import MyClient # from compiled code in
myclient-1.0-py2.6.egg


Again, it might seem like a headache to some python developers, but it
replicates fairly well the java way of keeping code 

Re: PYTHONPATH and multiple python versions

[Red Forks]

maybe a shell script to switch PYTHONPATH, like:
start-python-2.5
start-python-2.4 ...
On Fri, Jun 5, 2009 at 4:56 PM, David Cournapeau courn...@gmail.com wrote:

 Hi,

 As I don't have admin privileges on my main dev machine, I install a
 good deal of python modules somewhere in my $HOME, using PYTHONPATH to
 point my python intepreter to the right location. I think PEP370
 (per-user site-packages) does exactly what I need, but it works only
 for python 2.6 and above. Am I out of luck for versions below ?

 David
 --
 http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH and multiple python versions

[Javier Collado]

Hello,

I think that virtualenv could also do the job.

Best regards,
Javier

2009/6/5 Red Forks redfo...@gmail.com:
 maybe a shell script to switch PYTHONPATH, like:
 start-python-2.5
 start-python-2.4 ...
 On Fri, Jun 5, 2009 at 4:56 PM, David Cournapeau courn...@gmail.com wrote:

 Hi,

 As I don't have admin privileges on my main dev machine, I install a
 good deal of python modules somewhere in my $HOME, using PYTHONPATH to
 point my python intepreter to the right location. I think PEP370
 (per-user site-packages) does exactly what I need, but it works only
 for python 2.6 and above. Am I out of luck for versions below ?

 David
 --
 http://mail.python.org/mailman/listinfo/python-list


 --
 http://mail.python.org/mailman/listinfo/python-list


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH var

[Steven D'Aprano]

On Fri, 29 May 2009 03:50:54 -0700, insfor wrote:

 Hi guys. I have a question regarding runtime definition of the variable
 PYTHONPATH. Do you know how without modifying of source code change the
 value for this var.

Syntax error:  sentence seems to be a question, but is missing a 
question mark.

To answer your question, PYTHONPATH is an environment variable. You set 
it in your shell. For example, I use the bash shell under Linux, and in 
my .bashrc file I have this line:

export PYTHONPATH=/home/steve/python/

Every time I log in, the shell sets the environment variable to the 
pathname /home/steve/python/, and then when Python runs, it appends that 
path to sys.path. I don't have to modify any Python source code.



 Value stores in the system var sys.path, but the
 first item of this list, path[0], is the directory containing the script
 that was used to invoke the Python interpreter. We need to change this
 value which allows to us import scripts first from directory containing
 newest hotfix scripts without replacing original project scripts. One of
 the variant is to create script which will modify this var and insert
 line with import this script into each project script. So the question
 does another way exist? For example, parameter or argument for python
 launcher.

I don't understand what you are actually trying to say here. Perhaps you 
can explain a little bit more carefully?


However, trying to guess what you want, PYTHONPATH doesn't *replace* 
sys.path, it appends to the end of it. This is usually the right thing to 
do. However, sys.path is an ordinary list. If you want to modify it, you 
can do so:

import sys
sys.path[0] = '/some/other/path'



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH var

[Dave Angel]

Sergey Dikovitsky wrote:

Hi guys. I have a question regarding runtime definition of the variable
PYTHONPATH. Do you know how without modifying of source code change the
value for this var. Value stores in the system var sys.path, but the first
item of this list, path[0], is the directory containing the script that was
used to invoke the Python interpreter. We need to change this value which
allows to us import scripts first from directory containing newest hotfix
scripts without replacing original project scripts. One of the variant is to
create script which will modify this var and insert line with import this
script into each project script. So the question does another way exist? For
example, parameter or argument for python launcher.

  
I have to guess much of what you're talking about.  So if this is way 
off, try responding with a clearer wording.


PYTHONPATH is an environment variable.  You change that using your 
operating system's scripting language (shell script).


But you're talking about changing the first entry in sys.path, a Python 
list, which is generated from PYTHONPATH and a few other sources.  So it 
must be changed as Python is starting, not in the shell.


It is an ordinary list, and may be changed in the usual way.  So a 
script could start with:

  import sys
  sys.path = [newpath] + sys.path

(although you'd probably want to use a variable, not a literal)

But you say without modifying of source code.  Not clear what that 
means, without you qualifying just which source code is sacrosanct.


It seems you're trying to change the search order for the initial 
script.  But there is no search order.  You give an actual filename to 
the interpreter, and it does not search at all.  So perhaps what you 
really want is to modify the PATH variable before running the script.  
Then the operating system will search for it before trying to execute 
it.  This should work as long as you don't need any other switches on 
the python.exe command line.


You need to specify your system environment (Windows, Linux, ...), and 
probably your Python version.  And make it clearer what your real goal is.


--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH on Windows XP module load problem

[Andreas Otto]

Hi,

  I setup the PYTHONPATH environment variable too

  does windows use this variable ?


mfg

  Andreas Otto
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH on Windows XP module load problem

[Andreas Otto]

Hi,

  I solved the problem ...
  thank you for your help


mfg

  Andreas Otto
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH on Windows XP module load problem

[Andreas Otto]

Hi,

  I try to use distutils and setup.py to create an C extension

  Now a list of problems:

  1. I'm using automake, autoconf to setup the build-environment
for example CPPFLAGS

- how can I transport the CPPFLAGS on the commandline
to setup.py 

I can not use the define_macros argument in the setup.py
script

  2. the following shared library is created:

build/lib.linux-x86_64-3.0/pymsgque.so

- in my tool a test environment is included this mean
after a build but before install a test is
done. this mean that the library have to be found
and used by the test-environment.

- the problem is that the directory name
build/lib.linux-x86_64-3.0/
is system-depend

- question: how I get an unique system independent name
or just in general how I solve this kind of problem

  3. why is no .pyd file created ?

- pyd is the extension name supported 


mfg

  Andreas Otto


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH on Windows XP module load problem

[Andreas Otto]

Hi,

  after we know how your bathroom looks like ...

  I have done additional research.

1. setup a setup.py script
2. compiled the extension
3. copy the extension to the test directory
- cp ../pymsgque/build/lib.win32-3.0-pydebug/pymsgque.pyd .
4. start the test

$ python_d.exe ./server.py
Traceback (most recent call last):
  File ./server.py, line 13, in module
import pymsgque
ImportError: No module named pymsgque
[31909 refs]

- same as before

Question:

- is the module was not found or
could a found module not be loaded

mfg

  Andreas Otto
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH on Windows XP module load problem

[Scott David Daniels]

Andreas Otto wrote:

I have done additional research.
 1. setup a setup.py script
 2. compiled the extension
 3. copy the extension to the test directory
 - cp ../pymsgque/build/lib.win32-3.0-pydebug/pymsgque.pyd .

This doesn't work.  Windows is beseiged by trojan writers.  Just as the
various shell authors on *ix stopped executing commands from files in
the current directory unless explicitly invoked via './ls' (for
example), on windows care is taken to avoid libraries from the
current directory.  Normally one solves this with python setup.py
install, but you could also do look at the places Python searches
for its loadable modules, and putting the copy in one of those places,
choosing (of course) one earlier in the search than the copy you
intend to override.

You want to keep your *ix model, and that just doesn't work (I take
as evidence your use of a cp command above).  I suggest you will
keep stubbing your toe on the next thing that doesn't work quite like
*ix.  To port software is not to simulate your favorite operating
system on the target architecture and then run your app there, but
to understand the target environment and work to fit the software
there.  If you aren't going to put in the time to learn that
target environment, just go with distutils model.  It will then
at least be easy to make installers for the target system.

So, for example, I build with mingw32, not the full-blown gcc
environment when working on Windows at home.  When at work, it is
my employer's choice what tools I use (Visual C/C++, Intel C/C++ on
Windows usually; more varied on *ix).

--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH on Windows XP module load problem

[MRAB]

Andreas Otto wrote:

Hi,

  I have the following problem using python on windows.
  I crated a binary extension called

pymsgque.dll

  on windows. The same extension works fine on UNIX/Linux.

  The problem is on Windows. The build is no problem 
  but python is not able to load this extension with


import pymsgque

  and create the following error:

  Traceback (most recent call last):
  File server.py, line 13, in module
import pymsgque
ImportError: No module named pymsgque
[31906 refs]

  the PYTHONPATH variable has the directory of
  pymsgque.dll location

  the build of python and the pymsgque extension was done using
 Microsoft Visual C++ Express Edition

  it seems that I missing something

mfg

  Andreas Otto


Does this help?

http://pyfaq.infogami.com/is-a-pyd-file-the-same-as-a-dll

--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH on Windows XP module load problem

[Andreas Otto]

MRAB wrote:

 Andreas Otto wrote:
 Hi,
 
   I have the following problem using python on windows.
   I crated a binary extension called
 
 pymsgque.dll
 
   on windows. The same extension works fine on UNIX/Linux.
 
   The problem is on Windows. The build is no problem
   but python is not able to load this extension with
 
 import pymsgque
 
   and create the following error:
 
   Traceback (most recent call last):
   File server.py, line 13, in module
 import pymsgque
 ImportError: No module named pymsgque
 [31906 refs]
 
   the PYTHONPATH variable has the directory of
   pymsgque.dll location
 
   the build of python and the pymsgque extension was done using
  Microsoft Visual C++ Express Edition
 
   it seems that I missing something
 
 mfg
 
   Andreas Otto
 
 Does this help?
 
 http://pyfaq.infogami.com/is-a-pyd-file-the-same-as-a-dll

Hi,

  this link is nice but I'm still confused ...

  1. on LINUX I create a pymsgque.so and I can load this library
with import pymsgque

  2. in WINDOWS, I expect to create a pymsgque.dll and do the
same as on unix import pymgque

- is this behaviour is supported or not ???
 
  3. the hint with *.pyd is totally new to me and I don't know
is this the official way to use dll's on windows or
just a hack which works


mfg

  Andreas Otto

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH on Windows XP module load problem

[Christian Heimes]

Andreas Otto wrote:
   1. on LINUX I create a pymsgque.so and I can load this library
 with import pymsgque
 
   2. in WINDOWS, I expect to create a pymsgque.dll and do the
 same as on unix import pymgque
 
 - is this behaviour is supported or not ???
  
   3. the hint with *.pyd is totally new to me and I don't know
 is this the official way to use dll's on windows or
 just a hack which works

The suffix of Python extension has changed over time. It used to be .dll
but starting with Python 2.5 only .pyd files are imported. A .pyd file
is an ordinary, renamed dll file.

Christian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH on Windows XP module load problem

[Scott David Daniels]

Andreas Otto wrote:

Does this help?
http://pyfaq.infogami.com/is-a-pyd-file-the-same-as-a-dll


  this link is nice but I'm still confused ...

  1. on LINUX I create a pymsgque.so and I can load this library
with import pymsgque

And my bathroom is covered in wallpaper.


  2. in WINDOWS, I expect to create a pymsgque.dll and do the
same as on unix import pymgque

Surprise, surprise, surprise.  Your expectations do not match reality.
Why not expect to copy pymsgque.so over to Windows, as long as you
are busy expecting things?


- is this behaviour is supported or not ???
 
  3. the hint with *.pyd is totally new to me and I don't know

is this the official way to use dll's on windows or
just a hack which works


Yes, this is the official way.  The .pyd extension is a way of
stating a claim that the code follows the Python C module conventions.
Windows has certain conventions about the behavior of .dll files that
interfere with making these modules .dlls.

In case you are curious about the snarky attitude:
   (0) You asked a question.
   (1) You got an informative answer which allowed you to succeed.
   (2) You then explained what you expect to work; something you
   _know_ by experience does not work, and ask if it is supported.

Up until step 2, I was on your side.  To follow with a question asking
if something totally new to you is just a hack which works, when
your only alternative is the behavior you expected to work leaves me
thinking you trust the knowledge you gain from introspection over that
from experimentation or research.

Further, if you built modules using the suggested method, (writing a
setup.py, using python setup.py build; python setup.py install,
you would discover, by what I would guess to be your astonishment, that
a .pyd file got put in site-packages or wherever.


--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH on Mac 10.5

[Philip Semanchuk]

On Feb 25, 2009, at 3:20 PM, Vincent Davis wrote:


I have looked around for a good howto setup PYTHONPATH on Mac os x
10.5 Although I get many results I am not sure which is correct. I  
am not
sure if it is different for 10.5 over previous versions. Does anyone  
know of

a well documented set of instructions.

Is there a way to specify a module location or working directory?  
Which is

best? Or should I just add location to PYTHONPATH?



Hi Vincent,
There are different instructions on how to set PYTHONPATH because it  
solves a problem (how to organize one's Python modules) that has more  
than one solution. It's sort of like asking How should I organize my  
email? Different strokes for different folks.


Me, I don't use PYTHONPATH at all. Most of the stuff I want to import  
is already available in site-packages. If not, I can add a .pth file  
to site-packages that tells Python where to find the source. You can  
read about .pth files here:

http://docs.python.org/library/site.html



In my python scripts I specify which python I want to use like this
#!/Library/Frameworks/Python.framework/Versions/4.1.30101/bin/python


Yikes! Your scripts won't be too portable then, will they? I'm on OS X  
10.5 and I don't have a directory like that. A common, more portable  
alternative is this:


#!/usr/bin/env python

That relies (obviously) on /usr/bin/env being present which means that  
your scripts won't work on Windows machines, for instance. But it's a  
whole lot more portable than what you've got now. You don't need a  
shebang line at all if you're willing to launch your scripts by typing  
`python foo.py` at the command line. That will merely execute  
whichever python appears first in your path. I used to always use the / 
usr/bin/env shebang line that I described above, but I do so less  
often now. It's one less dependency to deal with.


So, in short, PYTHONPATH doesn't need to be set at all, and you can  
switch the shebang line to this:


#!/usr/bin/env python

Or do away with it entirely.

This isn't a complete answer but has it been at least somewhat helpful?

Cheers
Philip






--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH on Mac 10.5

[Python Nutter]

+1 for site packages and standard shebang, still lets you launch with
python first followed by .py file or big long path to a specific
python followed by .py file

also for some clues, just open up a terminal in your Mac OS X computer
and check out your exports your PATH will be different depending on
all the software and development environments you may or may not be
using on your Mac, in particular:

declare -x 
PATH=/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/Current/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

declare -x PYTHONSTARTUP=/Users/pythonnutter/.pythonstartup

for the ultra curious, my custom python startup:

$cat .pythonstartup
# python startup file
import readline
import rlcompleter
import atexit
import os
# tab completion
readline.parse_and_bind('tab: complete')
# history file
histfile = os.path.join(os.environ['HOME'], '.pythonhistory')
try:
readline.read_history_file(histfile)
except IOError:
pass
atexit.register(readline.write_history_file, histfile)
del os, histfile, readline, rlcompleter



On Windows you don't have much control in standard batch files but the
way I keep my Windows box (at work mind you, none at home)
multi-python'd

is I configure the environment for Framework 2.5.4, and all the path
environment variables are configured for the standard directory and
the scripts subdirectory.

in 25's scripts is go26.bat which just pre-pends the 2.6.1 path on the
head of PATH, and of course a go3.bat that pre-pends in 3.0.1

if you want to get fancy, since there is no pop in batch files that I
know of, you could drop a .py script in to read in PATH, pop off two
entries and modify the environment PATH so you fall back down the tree
(might need some list reversing in there to finish the massaging for
pops)

most times I get by with just exiting the terminal session in windows
and a new cmd session will once again take on the defaults for 2.5.4
--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH in Windows

[Diez B. Roggisch]

waltbrad schrieb:

PYTHONPATH is a concept I've never been able to get straight.  I can't
see the difference between this and just setting paths in the Windows
environment variables. So, for the longest time I just never worried
about it.

Now, I'm going through James Bennett's Practical Django Projects and
the issue raises it's head again.  We need to set up PYTHONPATH so
that python can find the directories for import statements. Can this
just be done through the environment variables?  Bennett says:

On Windows, the setup is a bit more involved, largely because
Windows, unlike UNIX-based systems, isn’t as friendly to command-line–
based programs. In the Control Panel’s System area, under the Advanced
tab, you can set environment variables. The PYTHONPATH variable should
already be set up with the initial value Python provided, and you can
add new directories to it (directories in the list should be separated
with semicolons).

But no PYTHONPATH variable shows up in my environment settings.  This
website:

http://www.imladris.com/Scripts/PythonForWindows.html

says you need to alter PYTHONPATH in the windows directory:

 Now that you've taught Windows to find the python executable in the
python install directory, you'll need to tell it how to find your
python scripts saved in folders other than that one; otherwise, your
python import statements will fail because they won't know where to
look for the custom modules you wish to import. Possible module
locations are specified by the PYTHONPATH environment variable, which
is stored in the Windows registry.

To augment PYTHONPATH, run regedit and navigate to KEY_LOCAL_MACHINE
\SOFTWARE\Python\PythonCore and then select the folder for the python
version you wish to use. Inside this is a folder labelled PythonPath,
with one entry that specifies the paths where the default install
stores modules. Right-click on PythonPath and choose to create a new
key. You may want to name the key after the project whose module
locations it will specify; this way, you can easily compartmentalize
and track your path modifications.

Your new key will have one string value entry, named (Default). Right-
click on it and modify its value data; this should be text in the same
format as the Path environment variable discussed above--absolute
directory paths, separated by semicolons. If one project will use
modules from several directories, add them all to this list. (Don't
bother attempting to add more string value entries to your new key, or
to the original PythonPath key, since they will be ignored.) Once
these new registry entries are in place, your scripts' import
statements should work fine.

I don't know when this was written, they refer to WIN 2000 but not
XP.  Is this correct?  Do I go into the registry and create a key and
type the path into it's string value?

I get pretty cautious about playing around with the registry.


Both result in the same - an environment-variable being added.

That no shows up when you do that for the first time isn't too much 
surprising - it doesn't exist, but you can create it.



However, I would strongly recommend *not* relying on a PYTHONPATH-variable.

Instead, go  install virtualenv. Then create a virtualenv for you 
django-project, and install django into it (however that is accomplished).


Then, go  install your codebase for your app into it as well. 
Preferably as egg-link. Should be easy enough with a minimal setup.py 
like this:


from setuptools import setup, find_packages
setup(
name = HelloWorld,
version = 0.1,
packages = find_packages(),
)


The advantage of this approach is that you can have several versions of 
your software installed in distinct VEs, for example for 
debugging/patching a released version, without having to meddle with the 
 PYTHONPATH everytime.


The important thing to remember ist just to always either activate the 
proper VE, or use the full path to the python executable inside it.


Diez
--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH in Windows

[waltbrad]

On Nov 29, 1:39 pm, Diez B. Roggisch [EMAIL PROTECTED] wrote:
 waltbrad schrieb:



  PYTHONPATH is a concept I've never been able to get straight.  I can't
  see the difference between this and just setting paths in the Windows
  environment variables. So, for the longest time I just never worried
  about it.

  Now, I'm going through James Bennett's Practical Django Projects and
  the issue raises it's head again.  We need to set up PYTHONPATH so
  that python can find the directories for import statements. Can this
  just be done through the environment variables?  Bennett says:

  On Windows, the setup is a bit more involved, largely because
  Windows, unlike UNIX-based systems, isn’t as friendly to command-line–
  based programs. In the Control Panel’s System area, under the Advanced
  tab, you can set environment variables. The PYTHONPATH variable should
  already be set up with the initial value Python provided, and you can
  add new directories to it (directories in the list should be separated
  with semicolons).

  But no PYTHONPATH variable shows up in my environment settings.  This
  website:

 http://www.imladris.com/Scripts/PythonForWindows.html

  says you need to alter PYTHONPATH in the windows directory:

   Now that you've taught Windows to find the python executable in the
  python install directory, you'll need to tell it how to find your
  python scripts saved in folders other than that one; otherwise, your
  python import statements will fail because they won't know where to
  look for the custom modules you wish to import. Possible module
  locations are specified by the PYTHONPATH environment variable, which
  is stored in the Windows registry.

  To augment PYTHONPATH, run regedit and navigate to KEY_LOCAL_MACHINE
  \SOFTWARE\Python\PythonCore and then select the folder for the python
  version you wish to use. Inside this is a folder labelled PythonPath,
  with one entry that specifies the paths where the default install
  stores modules. Right-click on PythonPath and choose to create a new
  key. You may want to name the key after the project whose module
  locations it will specify; this way, you can easily compartmentalize
  and track your path modifications.

  Your new key will have one string value entry, named (Default). Right-
  click on it and modify its value data; this should be text in the same
  format as the Path environment variable discussed above--absolute
  directory paths, separated by semicolons. If one project will use
  modules from several directories, add them all to this list. (Don't
  bother attempting to add more string value entries to your new key, or
  to the original PythonPath key, since they will be ignored.) Once
  these new registry entries are in place, your scripts' import
  statements should work fine.

  I don't know when this was written, they refer to WIN 2000 but not
  XP.  Is this correct?  Do I go into the registry and create a key and
  type the path into it's string value?

  I get pretty cautious about playing around with the registry.

 Both result in the same - an environment-variable being added.

 That no shows up when you do that for the first time isn't too much
 surprising - it doesn't exist, but you can create it.

 However, I would strongly recommend *not* relying on a PYTHONPATH-variable.

 Instead, go  install virtualenv. Then create a virtualenv for you
 django-project, and install django into it (however that is accomplished).

 Then, go  install your codebase for your app into it as well.
 Preferably as egg-link. Should be easy enough with a minimal setup.py
 like this:

 from setuptools import setup, find_packages
 setup(
      name = HelloWorld,
      version = 0.1,
      packages = find_packages(),
 )

 The advantage of this approach is that you can have several versions of
 your software installed in distinct VEs, for example for
 debugging/patching a released version, without having to meddle with the
   PYTHONPATH everytime.

 The important thing to remember ist just to always either activate the
 proper VE, or use the full path to the python executable inside it.

 Diez

This just sounds like you're making everything even more complicated.
Am I going to have to uninstall Python and Django and erase everything
I've done so far to use this?

I'm not real great at python. I know a little bit, enough to follow
what's going on with django so far, but it's all uphill.

But it sounds like your solution is to stop everything and learn about
another package before I can continue learning about django.

I got on the web and tried to look for a tutorial on this package. I
sort of understand what is being said:  All this technology is
constantly being upgraded and the upgrades can break the code you've
already written and got working. So, I can see the importance of it.
It sort of copies over the code you are currently using in a project/
app and insulates it from upgrades.

But what is the learning curve on this? Being a 

Re: PYTHONPATH in Windows

[Martin v. Löwis]

 But no PYTHONPATH variable shows up in my environment settings.

To answer a long question with a single sentence: just add the variable,
and be done with it.

Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH and modules

[Bruno Desthuilliers]

Juan a écrit :

Hi

I am programming a little script that makes use of a module I
developed before. The utils are inside the directory src of the
directory utils, and the package is nutum.utils. The script is in the
directory src inside the directory sysinfo, and the package is
nutum.sysinfo.


Won't work, cf below.


Well, if not clear, this is the list of files:

ls -lR ~/workspace (imaginary output):

utils/src/nutum/__init__.py
utils/src/nutum/utils/__init__.py
utils/src/nutum/utils/general.py
utils/src/nutum/utils/elapsed_time.py
utils/src/nutum/utils/execute_command.py
utils/src/nutum/utils/size_units.py

sysinfo/src/nutum/__init__.py
sysinfo/src/nutum/sysinfo/__init__.py
sysinfo/src/nutum/sysinfo/sysinfo.py
sysinfo/src/nutum/sysinfo/modules/__init__.py
sysinfo/src/nutum/sysinfo/modules/base_module.py
sysinfo/src/nutum/sysinfo/modules/os.py


A Python package is a filesystem directory with an __init__.py file in 
it. In your above layout, you have two *distinct, unrelated* packages 
both named nutum. The first found in sys.path will shadow the second.


You either need to rename one, or refactor your layout to have utils 
and sysinfo under the same root package, ie:


workspace/src/nutum/__init__.py
workspace/src/nutum/utils/__init__.py
workspace/src/nutum/utils/general.py
workspace/src/nutum/utils/elapsed_time.py
workspace/src/nutum/utils/execute_command.py
workspace/src/nutum/utils/size_units.py
workspace/src/nutum/sysinfo/__init__.py
workspace/src/nutum/sysinfo/sysinfo.py
workspace/src/nutum/sysinfo/modules/__init__.py
workspace/src/nutum/sysinfo/modules/base_module.py
workspace/src/nutum/sysinfo/modules/os.py

HTH
--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH breaks MySQLdb

[Diez B. Roggisch]

Aljosa Mohorovic schrieb:

i have a working MySQLdb module (/usr/lib/python2.4/site-packages/
MySQL_python-1.2.2-py2.4-linux-i686.egg), using it without problems.

clean shell after login:
python -c import MySQLdb reports no errors

if i export PYTHONPATH:
export PYTHONPATH=/var/www/projects/uv_portal/portal

python -c import MySQLdb reports no errors as in previous case

if i export PYTHONPATH:
export PYTHONPATH=/var/www/projects/uv_portal/portal/apps

i get this:
python -c import MySQLdb
Traceback (most recent call last):
  File string, line 1, in ?
ImportError: No module named MySQLdb

is there any reason why this happens?


Yes. You found a secret that nobody was supposed to know: Python doesn't 
allow portal applications te be written! So it scans the pythonpath for 
a suffix of portal/apps, and refuses to import anything if it finds it.


Seriously: yes, there must be a reason, but nobody can tell because we 
don't know  see what is beyond the apps-dir that might cause trouble. 
Generally speaking, given that you can properly import MySQLdb without 
any path set, you need to see if there is anything in your path that 
somehow gets imported first and e.g. alters the sys.path.


Try

python -vc 'import MySQLdb'

and if that doesn't make things clearer, use strace.

Diez
--
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH and PYTHON_PATH

[Christian Heimes]

loial wrote:
 Is there any difference?
 
 Does it matter which I use?

Yes, it does matter. The former is interpreted by Python, the latter isn't.

Christian


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH on OS X

[mhearne808[insert-at-sign-here]gmail[insert-dot-here]com]

On Oct 10, 4:59 pm, Graham Dumpleton [EMAIL PROTECTED]
wrote:
 On Oct 11, 8:00 am, mhearne808[insert-at-sign-here]gmail[insert-dot-



 here]com [EMAIL PROTECTED] wrote:
  I'm missing something major here.  I'm trying to add a directory to my
  python path using the PYTHONPATH environment variable, and it's being
  ignored by the Python interactive shell.

  Below is a capture of what I did.  Note that my newfolder appears
  nowhere on the list of directories in sys.path.  How do I get Python
  to pay attention to my shell variables?

  Using bash on OS X 10.4.10.

  %:~ user$ echo $PYTHONPATH

  %:~ user$ PYTHONPATH=/Users/user/newfolder
  %:~ user$ echo $PYTHONPATH
  /Users/user/newfolder
  %:~ user$ python
  Python 2.5.1 (r251:54863, Aug 10 2007, 10:46:58)
  [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
  Type help, copyright, credits or license for more information. 
  import sys
   sys.path

  ['', '/usr/local/lib/python2.5/site-packages/
  setuptools-0.7a1dev_r56320-py2.5.egg', '/usr/local/lib/python2.5/site-
  packages/ipython1-0.9alpha2-py2.5.egg', '/usr/local/lib/python2.5/site-
  packages/SQLAlchemy-0.4.0beta5-py2.5.egg', '/usr/local/lib/python2.5/
  site-packages/MySQL_python-1.2.2-py2.5-macosx-10.3-i386.egg', '/usr/
  local/lib/python25.zip', '/usr/local/lib/python2.5', '/usr/local/lib/
  python2.5/plat-darwin', '/usr/local/lib/python2.5/plat-mac', '/usr/
  local/lib/python2.5/plat-mac/lib-scriptpackages', '/usr/local/lib/
  python2.5/lib-tk', '/usr/local/lib/python2.5/lib-dynload', '/usr/local/
  lib/python2.5/site-packages', '/usr/local/lib/python2.5/site-packages/
  PIL']

 You need to export the environment variable.

   export PYTHONPATH

 Graham

Thanks all - I'm recently back to using Unix (Mac) after 5 years of
being on a PC.  I guess I thought export was just another way of doing
assignment.  My bad.

--Mike

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH on OS X

[Diez B. Roggisch]

mhearne808[insert-at-sign-here]gmail[insert-dot-here]com schrieb:
 I'm missing something major here.  I'm trying to add a directory to my
 python path using the PYTHONPATH environment variable, and it's being
 ignored by the Python interactive shell.
 
 Below is a capture of what I did.  Note that my newfolder appears
 nowhere on the list of directories in sys.path.  How do I get Python
 to pay attention to my shell variables?
 
 Using bash on OS X 10.4.10.
 
 %:~ user$ echo $PYTHONPATH
 
 %:~ user$ PYTHONPATH=/Users/user/newfolder
 %:~ user$ echo $PYTHONPATH
 /Users/user/newfolder
 %:~ user$ python
 Python 2.5.1 (r251:54863, Aug 10 2007, 10:46:58)
 [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
 Type help, copyright, credits or license for more information.
 import sys
 sys.path
 ['', '/usr/local/lib/python2.5/site-packages/
 setuptools-0.7a1dev_r56320-py2.5.egg', '/usr/local/lib/python2.5/site-
 packages/ipython1-0.9alpha2-py2.5.egg', '/usr/local/lib/python2.5/site-
 packages/SQLAlchemy-0.4.0beta5-py2.5.egg', '/usr/local/lib/python2.5/
 site-packages/MySQL_python-1.2.2-py2.5-macosx-10.3-i386.egg', '/usr/
 local/lib/python25.zip', '/usr/local/lib/python2.5', '/usr/local/lib/
 python2.5/plat-darwin', '/usr/local/lib/python2.5/plat-mac', '/usr/
 local/lib/python2.5/plat-mac/lib-scriptpackages', '/usr/local/lib/
 python2.5/lib-tk', '/usr/local/lib/python2.5/lib-dynload', '/usr/local/
 lib/python2.5/site-packages', '/usr/local/lib/python2.5/site-packages/
 PIL']

Use

export PYTHONPATH=

to pass environment vars to subprocesses.

Basic unix shell knowledge :)

$ man bash
...
   export -p
   The  supplied names are marked for automatic export to 
the envi-
   ronment of subsequently executed commands.  If the -f 
option  is
   given,  the names refer to functions.  If no names are 
given, or
   if the -p option is supplied, a  list  of  all  names 
that  are
   exported  in  this  shell  is printed.  The -n option 
causes the
   export property to be removed from the named variables. 
  export
   returns  an exit status of 0 unless an invalid option is 
encoun-
   tered, one of the names is not a valid shell variable 
name,  or
   -f is supplied with a name that is not a function.

...


Diez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH on OS X

[Anthony]

On Oct 10, 11:00 pm, mhearne808[insert-at-sign-here]gmail[insert-dot-
here]com [EMAIL PROTECTED] wrote:
 I'm missing something major here.  I'm trying to add a directory to my
 python path using the PYTHONPATH environment variable, and it's being
 ignored by the Python interactive shell.

 Below is a capture of what I did.  Note that my newfolder appears
 nowhere on the list of directories in sys.path.  How do I get Python
 to pay attention to my shell variables?

 Using bash on OS X 10.4.10.

 %:~ user$ echo $PYTHONPATH

 %:~ user$ PYTHONPATH=/Users/user/newfolder
 %:~ user$ echo $PYTHONPATH
 /Users/user/newfolder
 %:~ user$ python
 Python 2.5.1 (r251:54863, Aug 10 2007, 10:46:58)
 [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
 Type help, copyright, credits or license for more information. 
 import sys
  sys.path

 ['', '/usr/local/lib/python2.5/site-packages/
 setuptools-0.7a1dev_r56320-py2.5.egg', '/usr/local/lib/python2.5/site-
 packages/ipython1-0.9alpha2-py2.5.egg', '/usr/local/lib/python2.5/site-
 packages/SQLAlchemy-0.4.0beta5-py2.5.egg', '/usr/local/lib/python2.5/
 site-packages/MySQL_python-1.2.2-py2.5-macosx-10.3-i386.egg', '/usr/
 local/lib/python25.zip', '/usr/local/lib/python2.5', '/usr/local/lib/
 python2.5/plat-darwin', '/usr/local/lib/python2.5/plat-mac', '/usr/
 local/lib/python2.5/plat-mac/lib-scriptpackages', '/usr/local/lib/
 python2.5/lib-tk', '/usr/local/lib/python2.5/lib-dynload', '/usr/local/
 lib/python2.5/site-packages', '/usr/local/lib/python2.5/site-packages/
 PIL']

Try
export PYTHONPATH=/Users/user/newfolder

Otherwise (without 'export') the variable is defined in the shell but
not passed on when you launch python.

Cheers,
Anthony

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH on OS X

[Graham Dumpleton]

On Oct 11, 8:00 am, mhearne808[insert-at-sign-here]gmail[insert-dot-
here]com [EMAIL PROTECTED] wrote:
 I'm missing something major here.  I'm trying to add a directory to my
 python path using the PYTHONPATH environment variable, and it's being
 ignored by the Python interactive shell.

 Below is a capture of what I did.  Note that my newfolder appears
 nowhere on the list of directories in sys.path.  How do I get Python
 to pay attention to my shell variables?

 Using bash on OS X 10.4.10.

 %:~ user$ echo $PYTHONPATH

 %:~ user$ PYTHONPATH=/Users/user/newfolder
 %:~ user$ echo $PYTHONPATH
 /Users/user/newfolder
 %:~ user$ python
 Python 2.5.1 (r251:54863, Aug 10 2007, 10:46:58)
 [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
 Type help, copyright, credits or license for more information. 
 import sys
  sys.path

 ['', '/usr/local/lib/python2.5/site-packages/
 setuptools-0.7a1dev_r56320-py2.5.egg', '/usr/local/lib/python2.5/site-
 packages/ipython1-0.9alpha2-py2.5.egg', '/usr/local/lib/python2.5/site-
 packages/SQLAlchemy-0.4.0beta5-py2.5.egg', '/usr/local/lib/python2.5/
 site-packages/MySQL_python-1.2.2-py2.5-macosx-10.3-i386.egg', '/usr/
 local/lib/python25.zip', '/usr/local/lib/python2.5', '/usr/local/lib/
 python2.5/plat-darwin', '/usr/local/lib/python2.5/plat-mac', '/usr/
 local/lib/python2.5/plat-mac/lib-scriptpackages', '/usr/local/lib/
 python2.5/lib-tk', '/usr/local/lib/python2.5/lib-dynload', '/usr/local/
 lib/python2.5/site-packages', '/usr/local/lib/python2.5/site-packages/
 PIL']

You need to export the environment variable.

  export PYTHONPATH

Graham

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH, opensuse10.2, gtk not working

[Silfheed]

On Oct 4, 8:31 pm, Silfheed [EMAIL PROTECTED] wrote:
 On Oct 4, 7:39 pm, Steve Holden [EMAIL PROTECTED] wrote:



  Silfheed wrote:
   Heyas

   So I'm trying to do two things, install a little gnome taskbar applet
   (timer-applet) that was written in python and experiment with writing
   python gtk apps.  I've installed (through yast) gtk, gtk2, gtk2-devel,
   python-gtk, python-gtk-devl, python-gtk-doc but I still cant get
   python to import gtk.  I set PYTHONPATH = /usr/lib/python2.5/site-
   packages/ and that got importing pygtk to work, but the little app I
   downloaded wants to import gtk and I just cant figure out what I'm
   supposed to set PYTHONPATH to in order to get `import gtk` to work.
   Anyone know what I'm doing wrong or missing?

   Thanks

  set PYTHONPATH to /usr/lib/python2.5/lib/site-packages:gtk-root-dir

  By the way, do you really think that it's necessary to put site-packages
  on the path? You might find it's already on there as Python starts up.

  You can tell by printing sys.path from Python.

 Yes, it actually requires adding the site-packages to the PYTHONPATH
 to get pygtk to work.  So far I've managed to get gtk to give a
 different error when I added the site-packages/gtk-2.0/ directory (the
 only gtk-like thing in the site-packages) to the PYTHONPATH
 `ImportError: gobject/_gobject.so: undefined symbol:
 PyUnicodeUCS4_FromObject`.   I'll have to check the path when I get
 home to see what it actually has within it and work from there.

 Thanks.

So after checking sys.path and snooping around a bit more, it turns
out that I have two python site-package directories... one in /usr/lib
and one in /usr/local/lib.. One is automatically stuck into sys.path
(but allowed root access only) while the other is not.

I dunno why this is, but is there a way to get python to see both of
these automatically (without PYTHONPATH?)  Not that this solves my
problem since after changing the permissions to world readable on the
sys.path listed /usr/lib/python2.5/site-packages, it still wont let me
import gtk.  This is all after installing everything with yast (which
says that I have gtk)..

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH, opensuse10.2, gtk not working

[Silfheed]

On Oct 5, 1:04 pm, Silfheed [EMAIL PROTECTED] wrote:
 On Oct 4, 8:31 pm, Silfheed [EMAIL PROTECTED] wrote:



  On Oct 4, 7:39 pm, Steve Holden [EMAIL PROTECTED] wrote:

   Silfheed wrote:
Heyas

So I'm trying to do two things, install a little gnome taskbar applet
(timer-applet) that was written in python and experiment with writing
python gtk apps.  I've installed (through yast) gtk, gtk2, gtk2-devel,
python-gtk, python-gtk-devl, python-gtk-doc but I still cant get
python to import gtk.  I set PYTHONPATH = /usr/lib/python2.5/site-
packages/ and that got importing pygtk to work, but the little app I
downloaded wants to import gtk and I just cant figure out what I'm
supposed to set PYTHONPATH to in order to get `import gtk` to work.
Anyone know what I'm doing wrong or missing?

Thanks

   set PYTHONPATH to /usr/lib/python2.5/lib/site-packages:gtk-root-dir

   By the way, do you really think that it's necessary to put site-packages
   on the path? You might find it's already on there as Python starts up.

   You can tell by printing sys.path from Python.

  Yes, it actually requires adding the site-packages to the PYTHONPATH
  to get pygtk to work.  So far I've managed to get gtk to give a
  different error when I added the site-packages/gtk-2.0/ directory (the
  only gtk-like thing in the site-packages) to the PYTHONPATH
  `ImportError: gobject/_gobject.so: undefined symbol:
  PyUnicodeUCS4_FromObject`.   I'll have to check the path when I get
  home to see what it actually has within it and work from there.

  Thanks.

 So after checking sys.path and snooping around a bit more, it turns
 out that I have two python site-package directories... one in /usr/lib
 and one in /usr/local/lib.. One is automatically stuck into sys.path
 (but allowed root access only) while the other is not.

 I dunno why this is, but is there a way to get python to see both of
 these automatically (without PYTHONPATH?)  Not that this solves my
 problem since after changing the permissions to world readable on the
 sys.path listed /usr/lib/python2.5/site-packages, it still wont let me
 import gtk.  This is all after installing everything with yast (which
 says that I have gtk)..

Well.. I suppose a logical explanation would be two different installs
of python.. sorry for the noise.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH, opensuse10.2, gtk not working

[Steve Holden]

Silfheed wrote:
 Heyas
 
 So I'm trying to do two things, install a little gnome taskbar applet
 (timer-applet) that was written in python and experiment with writing
 python gtk apps.  I've installed (through yast) gtk, gtk2, gtk2-devel,
 python-gtk, python-gtk-devl, python-gtk-doc but I still cant get
 python to import gtk.  I set PYTHONPATH = /usr/lib/python2.5/site-
 packages/ and that got importing pygtk to work, but the little app I
 downloaded wants to import gtk and I just cant figure out what I'm
 supposed to set PYTHONPATH to in order to get `import gtk` to work.
 Anyone know what I'm doing wrong or missing?
 
 Thanks
 
set PYTHONPATH to /usr/lib/python2.5/lib/site-packages:gtk-root-dir

By the way, do you really think that it's necessary to put site-packages 
on the path? You might find it's already on there as Python starts up.

You can tell by printing sys.path from Python.

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd   http://www.holdenweb.com
Skype: holdenweb  http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline so I couldn't cat it

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH, opensuse10.2, gtk not working

[Silfheed]

On Oct 4, 7:39 pm, Steve Holden [EMAIL PROTECTED] wrote:
 Silfheed wrote:
  Heyas

  So I'm trying to do two things, install a little gnome taskbar applet
  (timer-applet) that was written in python and experiment with writing
  python gtk apps.  I've installed (through yast) gtk, gtk2, gtk2-devel,
  python-gtk, python-gtk-devl, python-gtk-doc but I still cant get
  python to import gtk.  I set PYTHONPATH = /usr/lib/python2.5/site-
  packages/ and that got importing pygtk to work, but the little app I
  downloaded wants to import gtk and I just cant figure out what I'm
  supposed to set PYTHONPATH to in order to get `import gtk` to work.
  Anyone know what I'm doing wrong or missing?

  Thanks

 set PYTHONPATH to /usr/lib/python2.5/lib/site-packages:gtk-root-dir

 By the way, do you really think that it's necessary to put site-packages
 on the path? You might find it's already on there as Python starts up.

 You can tell by printing sys.path from Python.

Yes, it actually requires adding the site-packages to the PYTHONPATH
to get pygtk to work.  So far I've managed to get gtk to give a
different error when I added the site-packages/gtk-2.0/ directory (the
only gtk-like thing in the site-packages) to the PYTHONPATH
`ImportError: gobject/_gobject.so: undefined symbol:
PyUnicodeUCS4_FromObject`.   I'll have to check the path when I get
home to see what it actually has within it and work from there.

Thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH not working on Windows XP (?)

[olivier]

Hi,

 Any suggestions for adding my path to sys.path permanently?

You can write a file in Lib/site-packages with a 'pth' extension (the
name itself doesn't matter) containing the path you want to add.

Example:
MyCustomLib.pth:
C:/docs/utils

And be careful with path separator on win32. It should be / or \\,
never \.

Regards,

 Olivier


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH not working on Windows XP (?)

[Sergio Correia]

Thanks!

It worked straightforward, and it's easier than messing with the
enviromental variables or the registry.

BTW, I'm still wondering how did Autohotkey got included in sys.path
(there are no other .pht files on my PC)

Regards,
Sergio

On 9/3/07, olivier [EMAIL PROTECTED] wrote:
 Hi,

  Any suggestions for adding my path to sys.path permanently?

 You can write a file in Lib/site-packages with a 'pth' extension (the
 name itself doesn't matter) containing the path you want to add.

 Example:
 MyCustomLib.pth:
 C:/docs/utils

 And be careful with path separator on win32. It should be / or \\,
 never \.

 Regards,

  Olivier


 --
 http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH or any other way to set seachpath (winXP) ?

[Gabriel Genellina]

En Sat, 03 Feb 2007 14:25:31 -0300, Stef Mientki  
[EMAIL PROTECTED] escribió:

 Is it possible to change the searchpath for modules on the flight,
 under winXP ?
 Most preferred is some command to extend the searchpath.
 (the environment variable PYTHONPATH needs a reboot)

PYTHONPATH is used to build the initial contents of sys.path, which is the  
actual list of directories searched. It's a standard list object so you  
can modify it easily.

-- 
Gabriel Genellina

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH or any other way to set seachpath (winXP) ?

[Rob Wolfe]

Stef Mientki [EMAIL PROTECTED] writes:

 Is it possible to change the searchpath for modules on the flight,
 under winXP ?
 Most preferred is some command to extend the searchpath.
 (the environment variable PYTHONPATH needs a reboot)

Do you mean something like that?

 import some_module
Traceback (most recent call last):
  File stdin, line 1, in ?
ImportError: No module named some_module
 import sys
 sys.path.append(..)
 import some_module

http://docs.python.org/tut/node8.html#SECTION00811

-- 
HTH,
Rob
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH or any other way to set seachpath (winXP) ?

[Stef Mientki]

 Do you mean something like that?
 
 import some_module
 Traceback (most recent call last):
   File stdin, line 1, in ?
 ImportError: No module named some_module
 import sys
 sys.path.append(..)
 import some_module
Rob,
thank you very much,
that's exactly what I want.
(Why is the obvious so often invisible to me ;-)

cheers,
Stef Mientki
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH or any other way to set seachpath (winXP) ?

[Jussi Salmela]

Stef Mientki kirjoitti:
 Is it possible to change the searchpath for modules on the flight,
 under winXP ?
What do you mean by *on the flight*: inside IDLE? using the command line?
 Most preferred is some command to extend the searchpath.
 (the environment variable PYTHONPATH needs a reboot)
 
No, it doesn't. PYTHONPATH can be updated somewhere in the environment 
options (sorry: I've got a Finnish language XP version, so I don't 
remember the exact terms) and the new path comes in effect immediately 
i.e. the launches after that see the new definition.

That way of changing the PYTHONPATH is a little difficult, though. In 
command line usage i.e. CMD.EXE I have been using these kinds of bat 
files to alternate between versions 2.4 and 2.5 of Python. (These were 
suggested earlier by someone in this group I think):
===
Py24.bat (Py25.bat has Python25 instead of Python24 in it)
===
@echo off
if .%1.==.. goto NODEV
set DEMOHOME=%1
goto CONT
:NODEV
set DEMOHOME=C:
:CONT
set PYTHONHOME=%DEMOHOME%\Python24
set PYTHONPATH=%PYTHONHOME%;
set PYTHON=%PYTHONHOME%\python.exe
set PYTHONW=%PYTHONHOME%\pythonw.exe
set PATH=%PYTHONHOME%;%PATH%

===
Py.bat (to launch Python)
===
%PYTHON% %1.py %2 %3 %4 %5 %6 %7 %8 %9

 thanks,
 Stef Mientki

HTH,
Jussi
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH or any other way to set seachpath (winXP) ?

[Stef Mientki]

Jussi Salmela wrote:
 Stef Mientki kirjoitti:
 Is it possible to change the searchpath for modules on the flight,
 under winXP ?
 What do you mean by *on the flight*: inside IDLE? using the command line?

No, I run Python, embedded from within a Delphi program.

 Most preferred is some command to extend the searchpath.
 (the environment variable PYTHONPATH needs a reboot)

 No, it doesn't. PYTHONPATH can be updated somewhere in the environment 
 options (sorry: I've got a Finnish language XP version, so I don't 
 remember the exact terms) and the new path comes in effect immediately 
 i.e. the launches after that see the new definition.
 
Through My computer | properties | advanced | Environment Variables
you have to reboot.
But as I remember well there should be a way, (through the registry or DOS-box 
?)
but I don't want to mess in the registry,
I want to keep my application portable.
But the suggestion of Rob, looks perfect.

thanks anyway,
Stef Mientki
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH or any other way to set seachpath (winXP) ?

[Inca]

 Through My computer | properties | advanced | Environment Variables
 you have to reboot.

The best overall solution is the one where you modify sys.path to add
your own custom paths, however Jussi is right in that you do not need
to reboot. You have to restart any applications that relies on using
the updated environment variables (in your case the Delphi program):

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/environment_variables.mspx?mfr=true

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH or any other way to set seachpath (winXP) ?

[Stef Mientki]

Inca wrote:
 Through My computer | properties | advanced | Environment Variables
 you have to reboot.
 
 The best overall solution is the one where you modify sys.path to add
 your own custom paths,
I agree, specially in my situation that is the best solution.

  however Jussi is right in that you do not need
 to reboot. You have to restart any applications that relies on using
 the updated environment variables (in your case the Delphi program):
 
 http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/environment_variables.mspx?mfr=true
 
I think the problem comes from the Delphi interface,
both Idle and PyScripter reflect a change PYTHONPATH after a restart.
But my Delphi program needs a reboot :-(
I'll ask around in the Python4Delphi newsgroup.

cheers,
Stef Mientki
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH or any other way to set seachpath (winXP) ?

[Ron Adam]

Stef Mientki wrote:
 Do you mean something like that?

 import some_module
 Traceback (most recent call last):
   File stdin, line 1, in ?
 ImportError: No module named some_module
 import sys
 sys.path.append(..)
 import some_module
 Rob,
 thank you very much,
 that's exactly what I want.
 (Why is the obvious so often invisible to me ;-)
 
 cheers,
 Stef Mientki

Just a note, If you run the module from different location, it may not always 
work.

The '..' is relative to the location you are running the module from, the 
current directory, and not relative to the location of the module is at.

It won't be a problem for you if you can be sure the module is always ran from 
the location it is at.

Cheers,
Ron

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH or any other way to set seachpath (winXP) ?

[Stef Mientki]

 Just a note, If you run the module from different location, it may not 
 always work.
 
 The '..' is relative to the location you are running the module from, 
 the current directory, and not relative to the location of the module is 
 at.
thanks for the tip Ron,
I didn't realized .. was literal ;-)
so I've changed my application, so it inserts the absolute path.

cheers,
Stef
 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH or any other way to set seachpath (winXP) ?

[Sick Monkey]

If you need to extend your PATH variable, I have used this in the past.
This should not require a reboot.
~~
def AddSysPath(new_path):
   new_path = os.path.abspath(new_path)
   do = -1
   if os.path.exists(new_path):
   do = 1
   # check against all paths currently available
   for x in sys.path:
   x = os.path.abspath(x)
   if sys.platform == 'win32':
   x = x.lower()
   if new_path in (x, x + os.sep):
   do = 0
   # add path if we don't already have it
   if do:
   sys.path.append(new_path)
   pass

   return do

On 2/3/07, Stef Mientki [EMAIL PROTECTED] wrote:


Is it possible to change the searchpath for modules on the flight,
under winXP ?
Most preferred is some command to extend the searchpath.
(the environment variable PYTHONPATH needs a reboot)

thanks,
Stef Mientki
--
http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PYTHONPATH vs PATH?

[Fredrik Lundh]

Michael Yanowitz wrote:

   Someone on my team tried out installing my Python code and
 found that setting PYTHONPATH does not work, but setting PATH
 environment variable works the way PYTHONPATH should. Is that
 how it supposed to be

PATH is used by the operating system to find executables, and PYTHONPATH
is used by Python to find Python modules.

why setting the PATH helped in your case is impossible to tell, without knowing
exactly what your application does.

/F 



-- 
http://mail.python.org/mailman/listinfo/python-list