Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Can somebody kill getpathp for me?

8 views
Skip to first unread message

Chris Gonnerman

unread,
Mar 1, 2002, 12:27:49 AM3/1/02
to
In the PC subdir of the Python-2.1.2 build directory is a module
called getpathp.c, which sets up the initial sys.path value. It
is well known by Python programmers on Windows that the sys.path
initialization includes directories plucked from special registry
keys... unless you are using the PythonWare version.

I thought, great, I can use this (the PythonWare version) to create
Python runnables on CD-ROM; but now I discover a fly in the ointment.
If the computer already has an installed Python interpreter, the
paths set in the registry are added, and BEFORE the paths from the
PythonWare PYROOT variable are added.

Gah.

What I want is a version of either python.exe or python21.dll
(whichever contains the offending getpathp.c module) with the
registry-probing code disabled. Ideally it should still apply
the paths from PYROOT (basically in this case it must).

Can anyone help with this? I am experienced in Linux programming
but a novice at Win32, and I don't have MSVC in any event. (Yeah,
I know, you can build Python with MinGW32, but it's a PITA.)

Chris Gonnerman -- chris.g...@newcenturycomputers.net
http://newcenturycomputers.net

Tim Peters

unread,
Mar 1, 2002, 1:23:59 AM3/1/02
to
[Chris Gonnerman]

> In the PC subdir of the Python-2.1.2 build directory is a module
> called getpathp.c, which sets up the initial sys.path value. It
> is well known by Python programmers on Windows that the sys.path
> initialization includes directories plucked from special registry
> keys... unless you are using the PythonWare version.

Or the PythonLabs distribution: while the core installer does set up a
registry entry containing "the usual" Python path, it *normally* never uses
it. Read the long comment block at the start of getpathp.c, and this time
believe that it means what it says <wink>. Note that the core installer
never sets up what the comment block calls "'application paths' - that is,
sub-keys under the main PythonPath registry key". If there aren't any
application paths, then, as the rest of the comment block says, the main
PythonPath key is ignored, unless a "Python Home" isn't given by a
PYTHONHOME envar and can't be guessed from the python.exe path.

> I thought, great, I can use this (the PythonWare version) to create
> Python runnables on CD-ROM; but now I discover a fly in the ointment.
> If the computer already has an installed Python interpreter, the
> paths set in the registry are added, and BEFORE the paths from the
> PythonWare PYROOT variable are added.

AFAIK PythonWare doesn't ship with a custom getpathp.c, and neither does
ActiveState, so AFAIK the comment block applies to all Python installations.
The "PythonWare PYROOT variable" is news to me, google hasn't heard of it
either, and I find no mention of PYROOT in my PythonWare PY21 installation.
Setting a PYROOT envar has no visible effect on sys.path when I run under
PY21 either. That's a long-winded way of saying I think you must be
confused <wink>.

Have you tried setting PYTHONHOME? If, e.g., I set PYTHONHOME to \Python22,
then execute python while *in* my \Python21 directory (these both referring
to PythonLabs distros), then Python 2.1.2 comes up with sys.path pointing
entirely at Python 2.2 directories. This is insane, but shows that
PYTHONHOME works the way getpathp.c says it works.

> Gah.
>
> What I want is a version of either python.exe or python21.dll
> (whichever contains the offending getpathp.c module) with the
> registry-probing code disabled.

If that's what you really want, you'll have to edit getpathp.c and compile
your own Python.

> Ideally it should still apply the paths from PYROOT (basically in this
> case it must).

Python doesn't look at any such envar on any platform. Maybe that's why
setting PYROOT isn't doing you any good <wink>. Try PYTHONHOME.


Chris Gonnerman

unread,
Mar 1, 2002, 8:22:06 AM3/1/02
to
----- Original Message -----
From: "Tim Peters" <tim...@comcast.net>


> [Chris Gonnerman]
> > In the PC subdir of the Python-2.1.2 build directory is a module
> > called getpathp.c, which sets up the initial sys.path value. It
> > is well known by Python programmers on Windows that the sys.path
> > initialization includes directories plucked from special registry
> > keys... unless you are using the PythonWare version.
>
> Or the PythonLabs distribution: while the core installer does set up a
> registry entry containing "the usual" Python path, it *normally* never
uses
> it. Read the long comment block at the start of getpathp.c, and this time
> believe that it means what it says <wink>.

From several places in that comment block:

Other "application paths" in the registry are always read.

I *don't* want this!

> Note that the core installer
> never sets up what the comment block calls "'application paths' - that is,
> sub-keys under the main PythonPath registry key". If there aren't any
> application paths, then, as the rest of the comment block says, the main
> PythonPath key is ignored, unless a "Python Home" isn't given by a
> PYTHONHOME envar and can't be guessed from the python.exe path.

No, but win32all does (for instance). The point is, I never want my
CD-based runtime to ever see the end user's install, if he/she has one.
The programs I want to run from CD may get psycho if the local version
has conflicting libraries, and in fact I have already encountered this
problem (so it's not just theoretical).

> > I thought, great, I can use this (the PythonWare version) to create
> > Python runnables on CD-ROM; but now I discover a fly in the ointment.
> > If the computer already has an installed Python interpreter, the
> > paths set in the registry are added, and BEFORE the paths from the
> > PythonWare PYROOT variable are added.
>
> AFAIK PythonWare doesn't ship with a custom getpathp.c, and neither does
> ActiveState, so AFAIK the comment block applies to all Python
installations.

Ah. Didn't know that.

> The "PythonWare PYROOT variable" is news to me, google hasn't heard of it
> either, and I find no mention of PYROOT in my PythonWare PY21
installation.
> Setting a PYROOT envar has no visible effect on sys.path when I run under
> PY21 either. That's a long-winded way of saying I think you must be
> confused <wink>.

Read the "setup.bat" file. I assumed it actually did something... my
mistake.

> Have you tried setting PYTHONHOME? If, e.g., I set PYTHONHOME to
\Python22,
> then execute python while *in* my \Python21 directory (these both
referring
> to PythonLabs distros), then Python 2.1.2 comes up with sys.path pointing
> entirely at Python 2.2 directories. This is insane, but shows that
> PYTHONHOME works the way getpathp.c says it works.

Here's my result (formatting corrected, content same):

K:\Python>set pythonhome=k:\python

K:\Python>set path=k:\python

K:\Python>python
Python 2.1.1 (#20, Aug 23 2001, 11:27:17) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
Alternative ReadLine 1.5 -- Copyright 2001, Chris Gonnerman
>>> import sys
>>> sys.path
['', 'C:\\Python\\win32', 'C:\\Python\\win32\\lib', 'C:\\Python',
'C:\\Python\\Pythonwin', 'k:\\python\\DLLs', 'k:\\python\\lib',
'k:\\python\\lib\\plat-win', 'k:\\python\\lib\\lib-tk', 'K:\\PYTHON',
'k:\\python\\PIL', 'k:\\python\\PST', 'k:\\python\\pythonware']
>>>

Note in particular that the Alternative Readline has been loaded. It
shouldn't be; I didn't put it in the k:\python install, only my python.org
"standard" install on the C drive. It seems to have already run when
site.py is loaded (I considered hacking sys.path there).

> > What I want is a version of either python.exe or python21.dll
> > (whichever contains the offending getpathp.c module) with the
> > registry-probing code disabled.
>
> If that's what you really want, you'll have to edit getpathp.c and compile
> your own Python.

It's beginning to look that way. Dang. That's going to be a lot of
work. I build software with MinGW32 from time to time, but I don't have
a working CygWin install, which seems to be necessary to run the
configure script. Frankly, no insult intended, I'd like to keep CygWin
off my computer; I tried programming with it and found it very
disappointing.

> > Ideally it should still apply the paths from PYROOT (basically in this
> > case it must).
>
> Python doesn't look at any such envar on any platform. Maybe that's why
> setting PYROOT isn't doing you any good <wink>. Try PYTHONHOME.

As I pointed out, I found the setup.bat file confusing; however PYTHONHOME
isn't helping either.

David Bolen

unread,
Mar 1, 2002, 1:59:55 PM3/1/02
to
"Chris Gonnerman" <chris.g...@newcenturycomputers.net> writes:

> No, but win32all does (for instance). The point is, I never want my
> CD-based runtime to ever see the end user's install, if he/she has one.
> The programs I want to run from CD may get psycho if the local version
> has conflicting libraries, and in fact I have already encountered this
> problem (so it's not just theoretical).

You may not technically need to package things up, but if you use
Gordon McMillan's installer (or py2exe as well as I believe), they
will lock down your sys.path to the local installation. So you could
build an image for your application using one of those tools, and
execute that from the CD.

Of course, this may not be perfect if you want the CD to work on both
Windows and Unix, but it would avoid needing to rebuild a different
python front-end for Windows.

--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/

Mark Hammond

unread,
Mar 3, 2002, 1:43:15 AM3/3/02
to
Tim Peters wrote:
> [Chris Gonnerman]

> Have you tried setting PYTHONHOME? If, e.g., I set PYTHONHOME to \Python22,
> then execute python while *in* my \Python21 directory (these both referring
> to PythonLabs distros), then Python 2.1.2 comes up with sys.path pointing
> entirely at Python 2.2 directories. This is insane, but shows that
> PYTHONHOME works the way getpathp.c says it works.

insane by design ;) PYTHONHOME was supposed to be a global override.

Didn't someone promise to document all this once? <wink>

>>What I want is a version of either python.exe or python21.dll
>>(whichever contains the offending getpathp.c module) with the
>>registry-probing code disabled.
>>
>
> If that's what you really want, you'll have to edit getpathp.c and compile
> your own Python.

Or, use MSVC or some other resource editor to change the single string
resource in the compiled Pythonxx.DLL (ie, no need to rebuild the DLL).
This will cause a different registry key to be used (by the core, and
also by extensions that are registry aware).

Mark.

Chris Gonnerman

unread,
Mar 3, 2002, 2:04:28 AM3/3/02
to
----- Original Message -----
From: "Mark Hammond" <mham...@skippinet.com.au>


> Tim Peters wrote:
> > [Chris Gonnerman]
>

> >>What I want is a version of either python.exe or python21.dll
> >>(whichever contains the offending getpathp.c module) with the
> >>registry-probing code disabled.
> >>
> >
> > If that's what you really want, you'll have to edit getpathp.c and
compile
> > your own Python.
>
> Or, use MSVC or some other resource editor to change the single string
> resource in the compiled Pythonxx.DLL (ie, no need to rebuild the DLL).
> This will cause a different registry key to be used (by the core, and
> also by extensions that are registry aware).

If I had MSVC I'd build from source. I work in a mixed Linux/Windows
environment, and use Python for just about everything. My days as
a C programmer are probably mostly in the past.

Wonder if I can find some other resource editing tool... time to STFW.

Tim Peters

unread,
Mar 4, 2002, 3:53:18 AM3/4/02
to
[Tim]

> If, e.g., I set PYTHONHOME to \Python22, then execute python while *in*
> my \Python21 directory (these both referring to PythonLabs distros),
> then Python 2.1.2 comes up with sys.path pointing entirely at Python 2.2
> directories. This is insane, but shows that PYTHONHOME works the way
> getpathp.c says it works.

[Mark Hammond]


> insane by design ;) PYTHONHOME was supposed to be a global override.

What's insane is that *I* would do such a thing, not that PYTHONHOME
believes me. It's great that PYTHONHOME believes me.

The other form of insanity is that there is no "global override" for *all*
of sys.path. Indeed, the lack of a global, no-kidding, I-really-mean-it,
don't-you-dare-try-to-outguess-me-at-all override is exactly Chris's
problem.

> Didn't someone promise to document all this once? <wink>

Well, you did, but you were Australian then, and we won't hold you to what
you promised before you became a tad civilized <wink>.

> ...


> Or, use MSVC or some other resource editor to change the single string
> resource in the compiled Pythonxx.DLL (ie, no need to rebuild the DLL).
> This will cause a different registry key to be used (by the core, and
> also by extensions that are registry aware).

Hmm. In the absence of a global no-kidding whole-sys.path override, maybe
someone would like to contribute a Python script to fiddle the DLL. *That*
should end this thread <wink>.

you-can-lead-a-python-to-a-rat-but-you-can't-make-it-eat-ly y'rs - tim


Chris Gonnerman

unread,
Mar 4, 2002, 11:54:50 AM3/4/02
to
----- Original Message -----
From: "Tim Peters" <tim...@comcast.net>


> [Tim]
> > If, e.g., I set PYTHONHOME to \Python22, then execute python while *in*
> > my \Python21 directory (these both referring to PythonLabs distros),
> > then Python 2.1.2 comes up with sys.path pointing entirely at Python 2.2
> > directories. This is insane, but shows that PYTHONHOME works the way
> > getpathp.c says it works.
>
> [Mark Hammond]
> > insane by design ;) PYTHONHOME was supposed to be a global override.
>
> What's insane is that *I* would do such a thing, not that PYTHONHOME
> believes me. It's great that PYTHONHOME believes me.

But you still get the path elements from add-on libraries as well.
PYTHONHOME
doesn't work for me.

> The other form of insanity is that there is no "global override" for *all*
> of sys.path. Indeed, the lack of a global, no-kidding, I-really-mean-it,
> don't-you-dare-try-to-outguess-me-at-all override is exactly Chris's
> problem.

Yup. Why don't we have such a thing?

> > ...
> > Or, use MSVC or some other resource editor to change the single string
> > resource in the compiled Pythonxx.DLL (ie, no need to rebuild the DLL).
> > This will cause a different registry key to be used (by the core, and
> > also by extensions that are registry aware).
>
> Hmm. In the absence of a global no-kidding whole-sys.path override, maybe
> someone would like to contribute a Python script to fiddle the DLL.
*That*
> should end this thread <wink>.

I ended up changing two registry key values in the DLL using a hex editor.
It's a hack, but it works for me.

0 new messages