Can somebody kill getpathp for me?

[Chris Gonnerman]

----- Original Message -----
From: "Tim Peters" <tim.one at 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.