Import, how to change sys.path on Windows, and module naming?

[Jeremy Nicoll - news posts]

If I understand correctly, when I import something under Windows, Python
searches the directory that the executing script was loaded from, then other
directories as specified in "sys.path".

I assume there are standard locations inside my installed Python - in my
case inside: C:\Program Files\~P-folder\Python25 - where I could put my
modules and they'd automatically be found? But even if that's the norm, I
don't want to put my own modules in such directories, partly because a
uninstall or reinstall or upgrade of Python might lose my stuff, and partly
because I don't believe in mixing distributed code with home-grown code.

However I'm quite happy to have a line or three of code to alter sys.path
to suit my set-up, if that's a normal way to handle this problem. Where
does one do that?


Also, I presume that there's a risk that the module name that I give to any
of my utilities will clash with a present or future standard module's name.
Does that mean that I should give my own modules names like "JNfoo" rather
than "foo", etc? Or something like "JNutils.foo"?

 

[Steve Holden]

If I understand correctly, when I import something under Windows, Python
searches the directory that the executing script was loaded from, then other
directories as specified in "sys.path".

Technically, I believe it just puts the script's directory at the start
of sys.path, then uses sys.path as its module search path.

I assume there are standard locations inside my installed Python - in my
case inside: C:\Program Files\~P-folder\Python25 - where I could put my
modules and they'd automatically be found? But even if that's the norm, I
don't want to put my own modules in such directories, partly because a
uninstall or reinstall or upgrade of Python might lose my stuff, and partly
because I don't believe in mixing distributed code with home-grown code.

There's Lib/site-packages, which is where third-party code normally goes.

However I'm quite happy to have a line or three of code to alter sys.path
to suit my set-up, if that's a normal way to handle this problem. Where
does one do that?

Take a look at site.py, and see that it runs sitecustomize.py when present.

Also, I presume that there's a risk that the module name that I give to any
of my utilities will clash with a present or future standard module's name.
Does that mean that I should give my own modules names like "JNfoo" rather
than "foo", etc? Or something like "JNutils.foo"?

You can always be sure your own modules will be loaded in preference to
shadowing system modules if you put your directories on the path before
the standard directories, but most people don't spend a lot of time
worrying about this.

regards
Steve

 

[Jeremy Nicoll - news posts]

If I understand correctly, when I import something under Windows, Python
searches the directory that the executing script was loaded from, then
other directories as specified in "sys.path".

Sorry to followup my own question, but I ran

for p,q in enumerate(sys.path): print p, q

and got:

0 C:\Documents and Settings\Laptop\My Documents\JN_PythonPgms
1 C:\Program Files\~P-folder\Python25\Lib\idlelib
2 C:\WINDOWS\system32\python25.zip
3 C:\Program Files\~P-folder\Python25\DLLs
4 C:\Program Files\~P-folder\Python25\lib
5 C:\Program Files\~P-folder\Python25\lib\plat-win
6 C:\Program Files\~P-folder\Python25\lib\lib-tk
7 C:\Program Files\~P-folder\Python25
8 C:\Program Files\~P-folder\Python25\lib\site-packages
9 C:\Program Files\~P-folder\Python25\lib\site-packages\win32
10 C:\Program Files\~P-folder\Python25\lib\site-packages\win32\lib
11 C:\Program Files\~P-folder\Python25\lib\site-packages\Pythonwin

Does every Windows user have: 2 C:\WINDOWS\system32\python25.zip
in their sys.path? What's the point of having a zip in the path?

Also, looking in C:\WINDOWS\system32\ I don't actually have a file called
python25.zip, but I do have one called python25.dll - so has something gone
wrong in creation of sys.path?

 

[Steve Holden]

Sorry to followup my own question, but I ran

for p,q in enumerate(sys.path): print p, q

and got:

0 C:\Documents and Settings\Laptop\My Documents\JN_PythonPgms
1 C:\Program Files\~P-folder\Python25\Lib\idlelib
2 C:\WINDOWS\system32\python25.zip
3 C:\Program Files\~P-folder\Python25\DLLs
4 C:\Program Files\~P-folder\Python25\lib
5 C:\Program Files\~P-folder\Python25\lib\plat-win
6 C:\Program Files\~P-folder\Python25\lib\lib-tk
7 C:\Program Files\~P-folder\Python25
8 C:\Program Files\~P-folder\Python25\lib\site-packages
9 C:\Program Files\~P-folder\Python25\lib\site-packages\win32
10 C:\Program Files\~P-folder\Python25\lib\site-packages\win32\lib
11 C:\Program Files\~P-folder\Python25\lib\site-packages\Pythonwin

Does every Windows user have: 2 C:\WINDOWS\system32\python25.zip
in their sys.path? What's the point of having a zip in the path?

So that the files inside the zip can be imported as modules and
packsges, of course.

Also, looking in C:\WINDOWS\system32\ I don't actually have a file called
python25.zip, but I do have one called python25.dll - so has something gone
wrong in creation of sys.path?

No. I'm not sure why the zip file is on there by default.

regards
Steve

 

[Tim Roberts]

Does every Windows user have: 2 C:\WINDOWS\system32\python25.zip
in their sys.path? What's the point of having a zip in the path?

Starting with Python 2.4, Python is able to import modules directly from a
zip, as if it were a directory. It's a very handy feature for distributing
premade packages.

 

[bockman]

Jeremy Nicoll - news posts wrote:









So that the files inside the zip can be imported as modules and
packsges, of course.


No. I'm not sure why the zip file is on there by default.

regards
  Steve
--
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/- Nascondi testo tra virgolette -

- Mostra testo tra virgolette -

I believe the answer is in how the new import protocol (PEP 302)
works: when you install a new path handler in sys.import_hooks, this
is called for each element of sys.path; the path handler has two
options: either to raise
ImportError, which means that cannot handle the specific path, or to
return an object with the methods defined
in the PEP, which means that the returned object - and only that one -
will be used to import modules in the specific path.

This means that only one path handler can be used for each element of
sys.path. Therefore, if you want to add a
path handler that does not interfere with the other ones, one way to
do it is to add something in sys.path that
is rejected by all path handlers except yours. I believe that
python25.zip is that 'something' that is used by the
zipimporter path handler, which allows to import directly from zip
files.

I did something similar in my toy experiment with the import hooks,
half-believing that there was something I missed. Nice to see that the
'big guys' did the same trick
(unless of course I _did_ miss something and my guess is completely
wrong; I should have done some experiment
before posting, but I'm too lazy for that).

Ciao

 

[bockman]

(unless of course I _did_ miss something and my guess is completely
wrong; I should have done some experiment
before posting, but I'm too lazy for that).

Ciao

Oops... I tried removing python25.zip from sys.path, and I can still
import packages from zip files ...
so my guess was wrong and my lazyness has been punished

Ciao

 

[Gabriel Genellina]

On 3 Mar, 17:12, (e-mail address removed) wrote:

Oops... I tried removing python25.zip from sys.path, and I can still
import packages from zip files ...

Yes, python25.zip is in sys.path by default, not to enable zipimport
(which is enabled by default, if zlib is available), but to allow the
entire Python library to be distributed in a .zip

When Python starts, it imports site.py (and a *lot* of other modules, too
much for my taste); that script is responsible of building sys.path,
adding lib/site-packages and looking for .pth files and so. Before that,
sys.path contains a minimal set of dirs. If there were no .zip already in
sys.path, site.py (and all the modules it uses) should exist on an actual
directory already present on sys.path in order to be imported - so the
entire library could not reside on a zip file.
Having python25.zip in sys.path by default (*before* processing site.py)
allows to distribute the whole std library (and possibly other packages
too) in a single zip file.