[RFA] ignore PYTHONHOME environment variable.

[RFA] ignore PYTHONHOME environment variable.

[Joel Brobecker]

This is something I hinted during one of our discussion at this year's
GCC Summit.

If PYTHONHOME is defined in the environment, then Py_SetProgramName
does not use the program-name location to find the python library.
Instead, it follows the PYTHONHOME, which can cause problems if
it points to a different Python installation, particularly if that
installation is from a different version of Python.

gdb/ChangeLog:

        * python/python.c (_initialize_python): Call Py_SetPythonHome
        if GDB was configured with --with-python.

Tested on x86_64-linux. Ok to commit?

---
 gdb/python/python.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/gdb/python/python.c b/gdb/python/python.c
index d009be9..4f6f679 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -955,6 +955,12 @@ Enables or disables printing of Python stack traces."),
   Py_Initialize ();
   PyEval_InitThreads ();
 
+#ifdef WITH_PYTHON_PATH
+  /* We override any value that the PYTHONHOME might have, as we want
+     to make sure that we use the Python library that comes with GDB.  */
+  Py_SetPythonHome (ldirname (python_libdir));
+#endif
+
   gdb_module = Py_InitModule ("gdb", GdbMethods);
 
   /* The casts to (char*) are for python 2.4.  */
-- 
1.7.1

Re: [RFA] ignore PYTHONHOME environment variable.

[Jan Kratochvil]

On Tue, 23 Nov 2010 02:03:22 +0100, Joel Brobecker wrote:
> This is something I hinted during one of our discussion at this year's
> GCC Summit.
> 
> If PYTHONHOME is defined in the environment, then Py_SetProgramName
> does not use the program-name location to find the python library.
> Instead, it follows the PYTHONHOME, which can cause problems if
> it points to a different Python installation, particularly if that
> installation is from a different version of Python.

On standard Fedora 14 ./configure (no python options given) I get:
#define HAVE_LIBPYTHON2_7 1
#define HAVE_PYTHON 1
#define PYTHON_PATH_RELOCATABLE 0
#define WITH_PYTHON_PATH "/usr"

I am not a Python expect but I believe for GDB linked with the only regular
system Python $PYTHONHOME should work, even for GDB-Python.

Maybe it should be overriden only for the case of PYTHON_PATH_RELOCATABLE?
Or maybe only if --with-python=SPECIFIC-PATH has been given?

(I do not have an opinion what it should do in such case, just I think I know
what it should do in the default system Python case.)


Thanks,
Jan

Re: [RFA] ignore PYTHONHOME environment variable.

[Doug Evans]

On Mon, Nov 22, 2010 at 7:00 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Tue, 23 Nov 2010 02:03:22 +0100, Joel Brobecker wrote:
>> This is something I hinted during one of our discussion at this year's
>> GCC Summit.
>>
>> If PYTHONHOME is defined in the environment, then Py_SetProgramName
>> does not use the program-name location to find the python library.
>> Instead, it follows the PYTHONHOME, which can cause problems if
>> it points to a different Python installation, particularly if that
>> installation is from a different version of Python.
>
> On standard Fedora 14 ./configure (no python options given) I get:
> #define HAVE_LIBPYTHON2_7 1
> #define HAVE_PYTHON 1
> #define PYTHON_PATH_RELOCATABLE 0
> #define WITH_PYTHON_PATH "/usr"
>
> I am not a Python expect but I believe for GDB linked with the only regular
> system Python $PYTHONHOME should work, even for GDB-Python.
>
> Maybe it should be overriden only for the case of PYTHON_PATH_RELOCATABLE?
> Or maybe only if --with-python=SPECIFIC-PATH has been given?
>
> (I do not have an opinion what it should do in such case, just I think I know
> what it should do in the default system Python case.)

Hi.
I'm not sure I understand the objection.
AIUI, if gdb is linked with the system python then Joel's patch is
essentially a nop
(i.e. PYTHONHOME=/usr would still work).

[Right?]

Re: [RFA] ignore PYTHONHOME environment variable.

[Jan Kratochvil]

On Tue, 23 Nov 2010 10:29:05 +0100, Doug Evans wrote:
> On Mon, Nov 22, 2010 at 7:00 PM, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> > I am not a Python expect but I believe for GDB linked with the only regular
> > system Python $PYTHONHOME should work, even for GDB-Python.
[...]
> I'm not sure I understand the objection.
> AIUI, if gdb is linked with the system python then Joel's patch is
> essentially a nop
> (i.e. PYTHONHOME=/usr would still work).

But PYTHONHOME=$HOME for some user overrides of system Python would no longer
work.  What would $PYTHONHOME otherwise be useful for?

At least for $PERL5LIB I add $HOME{/share,/lib{,64}}/perl5 myself.  It seems
to me $PERL5LIB is in part $PYTHONHOME (.so) and $PYTHONPATH (.py).

[RFA] ignore PYTHONHOME environment variable.
http://sourceware.org/ml/gdb-patches/2010-11/msg00328.html


Regards,
Jan

Re: [RFA] ignore PYTHONHOME environment variable.

[Doug Evans]

On Tue, Nov 23, 2010 at 8:30 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> But PYTHONHOME=$HOME for some user overrides of system Python would no longer
> work.  What would $PYTHONHOME otherwise be useful for?

OTOH what if one wanted to debug a python with a different PYTHONHOME?
GDB_PYTHONHOME?  [not my idea, but seems reasonable]

Re: [RFA] ignore PYTHONHOME environment variable.

[Joel Brobecker]

> <jan.kratochvil@redhat.com> wrote:
> > But PYTHONHOME=$HOME for some user overrides of system Python would
> > no longer work.  What would $PYTHONHOME otherwise be useful for?
> 
> OTOH what if one wanted to debug a python with a different PYTHONHOME?
> GDB_PYTHONHOME?  [not my idea, but seems reasonable]

I think you indeed need something like that. I don't think we can trust
PYTHONHOME, because it might point to something that's incompatible.

GDB_PYTHONHOME is something that got suggested by at least 2 people
(someone at AdaCore also suggested it a while back).  I have to wonder,
though, why you would want to run GDB with a different version of Python
than then one used to build GDB with.  If you want to use your own
scripts, you can use the PYTHONPATH.

Still, we can add that too, something like that:

  #ifdef WITH_PYTHON_PATH
    if "GDB_PYTHONHOME" is defined
      Py_SetPythonHome (getenv ("GDB_PYTHONHOME"));
    else
      /* We override any value that the PYTHONHOME might have, as we want
         to make sure that we use the Python library that comes with GDB.  */
      Py_SetPythonHome (ldirname (python_libdir));
  #endif

But I think I would prefer something like this:

  if "GDB_PYTHONHOME" is defined
    Py_SetPythonHome (getenv ("GDB_PYTHONHOME"));
  #ifdef WITH_PYTHON_PATH
    else
      /* We override any value that the PYTHONHOME might have, as we want
         to make sure that we use the Python library that comes with GDB.  */
      Py_SetPythonHome (ldirname (python_libdir));
  #endif

The latter makes GDB_PYTHONHOME always active, regardless of how
GDB was linked against Python.

-- 
Joel

Re: [RFA] ignore PYTHONHOME environment variable.

[Joel Brobecker]

Hey Jan, Hey Doug,

I really apologize for the delay in getting back to this.

On Tue, Nov 23, 2010 at 09:30:54AM -0800, Joel Brobecker wrote:
> > <jan.kratochvil@redhat.com> wrote:
> > > But PYTHONHOME=$HOME for some user overrides of system Python would
> > > no longer work.  What would $PYTHONHOME otherwise be useful for?
> > 
> > OTOH what if one wanted to debug a python with a different PYTHONHOME?
> > GDB_PYTHONHOME?  [not my idea, but seems reasonable]
> 
> I think you indeed need something like that. I don't think we can trust
> PYTHONHOME, because it might point to something that's incompatible.

Jan: Does your objection still stand, or are you satisfied if we add
a GDB_PYTHONHOME environment variable to control the Python home?

Note that, if PYTHONHOME was used purely to access user scripts, then
they should be using PYTHONPATH instead.

> But I think I would prefer something like this:
> 
>   if "GDB_PYTHONHOME" is defined
>     Py_SetPythonHome (getenv ("GDB_PYTHONHOME"));
>   #ifdef WITH_PYTHON_PATH
>     else
>       /* We override any value that the PYTHONHOME might have, as we want
>          to make sure that we use the Python library that comes with GDB.  */
>       Py_SetPythonHome (ldirname (python_libdir));
>   #endif
> 
> The latter makes GDB_PYTHONHOME always active, regardless of how
> GDB was linked against Python.

Doug: Does this seem reasonable to you?

-- 
Joel

Re: [RFA] ignore PYTHONHOME environment variable.

[Jan Kratochvil]

On Tue, 14 Dec 2010 08:12:10 +0100, Joel Brobecker wrote:
> On Tue, Nov 23, 2010 at 09:30:54AM -0800, Joel Brobecker wrote:
> > > <jan.kratochvil@redhat.com> wrote:
> > > > But PYTHONHOME=$HOME for some user overrides of system Python would
> > > > no longer work.  What would $PYTHONHOME otherwise be useful for?
> > > 
> > > OTOH what if one wanted to debug a python with a different PYTHONHOME?
> > > GDB_PYTHONHOME?  [not my idea, but seems reasonable]
> > 
> > I think you indeed need something like that. I don't think we can trust
> > PYTHONHOME, because it might point to something that's incompatible.
> 
> Jan: Does your objection still stand, or are you satisfied if we add
> a GDB_PYTHONHOME environment variable to control the Python home?

GDB_PYTHONHOME may exist and it can override any other settings, why not.

Still $PYTHONHOME should apply for GDB, the same way as it applies for
any other package.  It is also the reason it exists.  One may want to override
system Python installation in $HOME, with proper $LD_LIBRARY_PATH and
$PYTHONHOME I hope it should work well, as it works for other software.
Your proposed way the user would have to troubleshoot (s)he needs to set also
$GDB_PYTHONHOME, besides $PYTHONHOME.


On Tue, 23 Nov 2010 18:30:54 +0100, Joel Brobecker wrote:
# GDB_PYTHONHOME is something that got suggested by at least 2 people
# (someone at AdaCore also suggested it a while back).

How many OS distributors have suggested it?  It is against the fundamental
distro policies.  Many reasons why bundling is broken are at:
	http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries


> > But I think I would prefer something like this:
> > 
> >   if "GDB_PYTHONHOME" is defined
> >     Py_SetPythonHome (getenv ("GDB_PYTHONHOME"));
> >   #ifdef WITH_PYTHON_PATH
> >     else
> >       /* We override any value that the PYTHONHOME might have, as we want
> >          to make sure that we use the Python library that comes with GDB.  */
> >       Py_SetPythonHome (ldirname (python_libdir));
> >   #endif
> > 
> > The latter makes GDB_PYTHONHOME always active, regardless of how
> > GDB was linked against Python.

This is a classical example of a vendor distribution patch which is not
expected to be present upstream.  Still I can override these downstream; just
I believe upstream should not contain any sych directory hacks.


If you want it upstream why to just make it disabled during default
./configure?  PYTHON_PATH_RELOCATABLE cannot be used as a conditional, during
--prefix=/usr with system Python one gets:

#define GDB_DATADIR_RELOCATABLE 1
#define PYTHONDIR "/usr/share/gdb/python"
#define PYTHON_PATH_RELOCATABLE 1
#define WITH_PYTHON_PATH "/usr"

Which also seems broken, though - why should system GDB use Python directories
depending on where the gdb binary is located?  I apparently missed the patch.

I would propose some extra new configure option to both enable
PYTHON_PATH_RELOCATABLE only in such case and also to possibly disable
respecting $PYTHONHOME.


Regards,
Jan

Re: [RFA] ignore PYTHONHOME environment variable.

[Joel Brobecker]

> On Tue, 23 Nov 2010 18:30:54 +0100, Joel Brobecker wrote:
> # GDB_PYTHONHOME is something that got suggested by at least 2 people
> # (someone at AdaCore also suggested it a while back).
> 
> How many OS distributors have suggested it?  It is against the fundamental
> distro policies.  Many reasons why bundling is broken are at:
> 	http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

I would rather not go there, for 2 reasons:

  1. Either the change is useful, or it is not; If not, then it does not
     go in;

  2. OS distros have very different operational needs compared to tool
     providers such as ourselves.

> This is a classical example of a vendor distribution patch which is
> not expected to be present upstream.  Still I can override these
> downstream; just I believe upstream should not contain any sych
> directory hacks.

I think that this is too general a criticism. I care more about
the FSF tree than I care about the AdaCore one, and I would not have
proposed this change if I thought that it would not be useful to other
people.

I understand that you don't like the patch, and I get the fact that
I don't seem to have changed my opinion much.  I assure you that
I will not press much further if the change of behavior does not
get either your approval or more general support from the other
maintainers.

> Still $PYTHONHOME should apply for GDB, the same way as it applies for
> any other package.  It is also the reason it exists.  One may want to override
> system Python installation in $HOME, with proper $LD_LIBRARY_PATH and
> $PYTHONHOME I hope it should work well, as it works for other software.
> Your proposed way the user would have to troubleshoot (s)he needs to set also
> $GDB_PYTHONHOME, besides $PYTHONHOME.

Please consider also the situation where the user sets PYTHONHOME to
a version of Python that is incompatible with the one we used to build
GDB, and then miserably crashes with no hint as to what the problem
might be.  This is what happened in my case, and the users had no clue
why GDB just crashed.

This may never happen in your context, because you control the entire
distro.  But some users install third-party code which they sometimes
compiled themselves, and then install it on the side.  Even outside
of AdaCore, I do it all the time (Eg: tools of specific versions that
I need for GDB development, or externally-provided binaries). I don't
install them in /usr or /usr/local because I want to be able to wipe
them anytime I want by a simple "rm -rf".

I tried to find other ways to find a compromise, and always end up
going back to the same principle: We simply cannot trust PYTHONHOME
to point to a version of Python that's compatible with the version
we used at build time. PYTHONHOME is for the Python executable. We
must try to use the Python library that we used to build GDB. And on
the rare cases that someone has its own Python library, and actually
wants GDB to use it, and knows that it's compatible, I can add
a GDB_PYTHON_PATH environment variable.

That way, GDB always behaves the same, regardless of how it's been
built. I think that this is a lot less confusing than having
configure-time switches that dramatically modify the behavior
in a way that is not necessarily obvious. KISS.

What we can also do is warn users when we see that PYTHONHOME is
defined and not GDB_PYTHON_HOME.  That way, they are not surprised
when that happens, and they get a helpful indication of how to
remedy the problem.  Maybe we can also introduce a command-line
switch that triggers one type of behavior or the other, but I think
we're getting in the overkill range.

> #define GDB_DATADIR_RELOCATABLE 1
> #define PYTHONDIR "/usr/share/gdb/python"
> #define PYTHON_PATH_RELOCATABLE 1
> #define WITH_PYTHON_PATH "/usr"
> 
> Which also seems broken, though - why should system GDB use Python
> directories depending on where the gdb binary is located?  I
> apparently missed the patch.

I don't know if the rest of the GNU tools make an exception for /usr
and /usr/local, or not.  But having your dependencies be relocatable
is a widespread practice that is extremely convenient (think of prefix.o
in the compiler, for instance, which allows me to copy a compiler
install at a different location). I think that the same convenience
is equally useful for tools installed in system locations such as /usr.

-- 
Joel

Re: [RFA] ignore PYTHONHOME environment variable.

[Joel Brobecker]

Given the lack of support and the resistance from Jan, this patch is
withdrawn. (I think that's a mistake! :-P)

-- 
Joel

Re: [RFA] ignore PYTHONHOME environment variable.

[Doug Evans]

On Thu, Jan 13, 2011 at 12:55 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> Given the lack of support and the resistance from Jan, this patch is
> withdrawn. (I think that's a mistake! :-P)

fwiw, I like GDB_PYTHONHOME.  I'd rather not punt on this.

I'm not sure I completely understand the objections to something like
the following:

if GDB_PYTHONHOME provided
  use it
elseif PYTHONHOME provided
  use it
else
  use default
endif

That way a user can provide a PYTHONHOME and gdb will use it.   But if
it is incompatible with the python that gdb is using, they can still
have PYTHONHOME - they just need to set GDB_PYTHONHOME too.

Re: [RFA] ignore PYTHONHOME environment variable.

[Jan Kratochvil]

On Sat, 15 Jan 2011 08:55:59 +0100, Doug Evans wrote:
> if GDB_PYTHONHOME provided
>   use it
> elseif PYTHONHOME provided
>   use it
> else
>   use default
> endif
> 
> That way a user can provide a PYTHONHOME and gdb will use it.   But if
> it is incompatible with the python that gdb is using, they can still
> have PYTHONHOME - they just need to set GDB_PYTHONHOME too.

I find this setup fine, Joel had some disagreements with it.


Thanks,
Jan

Re: [RFA] ignore PYTHONHOME environment variable.

[Joel Brobecker]

On Sat, Jan 15, 2011 at 12:09:17PM +0100, Jan Kratochvil wrote:
> On Sat, 15 Jan 2011 08:55:59 +0100, Doug Evans wrote:
> > if GDB_PYTHONHOME provided
> >   use it
> > elseif PYTHONHOME provided
> >   use it
> > else
> >   use default
> > endif
> > 
> > That way a user can provide a PYTHONHOME and gdb will use it.   But if
> > it is incompatible with the python that gdb is using, they can still
> > have PYTHONHOME - they just need to set GDB_PYTHONHOME too.
> 
> I find this setup fine, Joel had some disagreements with it.

I must have misunderstood, because I don't remember disagreeing to
this proposal.  I think that having a GDB_PYTHONHOME is a useful thing
to have, regardless of the disagreement on PYTHONHOME (which, I think,
is an orthogonal matter).

I'd say go for it.

-- 
Joel

Re: [RFA] ignore PYTHONHOME environment variable.

[Jan Kratochvil]

On Tue, 14 Dec 2010 11:33:05 +0100, Joel Brobecker wrote:
> What we can also do is warn users when we see that PYTHONHOME is
> defined and not GDB_PYTHON_HOME.  That way, they are not surprised
> when that happens, and they get a helpful indication of how to
> remedy the problem.

Therefore:

if ($GDB_PYTHONHOME exists) {
  use it
} else if ($PYTHONHOME exists) {
  warn on it
  ignore it
  pass it to spawned debuggees
} else {
  let Python use it's defaults
}

That "ignore it" part may be difficult as despite Py_SetPythonHome overrides
$PYTHONHOME if !defined WITH_PYTHON_PATH we do not know which string to use
for Py_SetPythonHome to override it.  So maybe to use unsetenv before
Py_Initialize and setenv the saved string back afterwards.

Also I believe it should apply to any environment starting with PYTHON* as
besides
	$ PYTHONHOME=/foo ./gdb
	ImportError: No module named site

it affects also at least
	$ echo foo >site.py; PYTHONPATH=. ./gdb
	Traceback (most recent call last):
	  File "./site.py", line 1, in <module>
	    foo
	NameError: name 'foo' is not defined

and
	$ PYTHONVERBOSE=1 ./gdb
	# installing zipimport hook
	import zipimport # builtin
	[...]
	import gdb.command.upto # precompiled from /usr/share/gdb/python/gdb/command/upto.pyc
	GNU gdb (GDB) 7.4.50.20120512-cvs
	[...]


Thanks,
Jan

Re: [RFA] ignore PYTHONHOME environment variable.

[Joel Brobecker]

Hi Jan,

On Fri, May 18, 2012 at 09:33:52PM +0200, Jan Kratochvil wrote:
> On Tue, 14 Dec 2010 11:33:05 +0100, Joel Brobecker wrote:
> > What we can also do is warn users when we see that PYTHONHOME is
> > defined and not GDB_PYTHON_HOME.  That way, they are not surprised
> > when that happens, and they get a helpful indication of how to
> > remedy the problem.

Just curious why you revived this discussion. I had written off
our changes in this area as vendor-specific, and given up on the
idea of putting it in the FSF tree for others to use.... Is there
something you need to fix on your side?

> Therefore:
> 
> if ($GDB_PYTHONHOME exists) {
>   use it
> } else if ($PYTHONHOME exists) {
>   warn on it
>   ignore it
>   pass it to spawned debuggees
> } else {
>   let Python use it's defaults
> }
> 
> That "ignore it" part may be difficult as despite Py_SetPythonHome
> overrides $PYTHONHOME if !defined WITH_PYTHON_PATH we do not know
> which string to use for Py_SetPythonHome to override it.  So maybe to
> use unsetenv before Py_Initialize and setenv the saved string back
> afterwards.

This is how we do it at AdaCore:

diff --git a/gdb/python/python.c b/gdb/python/python.c
index 9a80dea..cc95940 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -1222,6 +1222,10 @@ message == an error message without a stack will be printed."),
      This must be done before calling Py_Initialize.  */
   Py_SetProgramName (concat (ldirname (python_libdir), SLASH_STRING, "bin",
 			     SLASH_STRING, "python", NULL));
+
+  /* We override any value that the PYTHONHOME might have, as we want
+     to make sure that we use the Python library that comes with GDB.  */
+  Py_SetPythonHome (ldirname (python_libdir));
 #endif
 
   Py_Initialize ();

It doesn't look at GDB_PYTHONHOME because we have never encountered
a situation when we needed it. But does it answer your question about
"ignore it"? We "ignore" the PYTHON_HOME value by just forcing it
using Py_SetPythonHome.

> Also I believe it should apply to any environment starting with PYTHON* as
> besides

I less sure about that...

The purpose of the proposal to ignore PYTHONHOME is to make sure that
the user does not accidently use a Python install which is incompatible
with the version that GDB was built with. I am not sure whether we should
deal with PYTHONPATH, but it seems that letthing PYTHONVERBOSE through
would be OK or even desirable...

-- 
Joel

Re: [RFA] ignore PYTHONHOME environment variable.

[Jan Kratochvil]

Hi Joel,

On Mon, 28 May 2012 16:41:21 +0200, Joel Brobecker wrote:
> Is there something you need to fix on your side?

Yes, user has requested the same feature.  It is rather a decision what
should be general behavior across applications linking with libpython (not
just for GDB).  For example (yum is like AFAIK apt):
$ echo foo >site.py; PYTHONPATH=. yum list bash
Traceback (most recent call last):
  File "./site.py", line 1, in <module>
    foo
NameError: name 'foo' is not defined
$ _

VIM behaves the same (although its crashes only after first :python command).

Therefore I have filed distro-wide (sure to be only FYI for FSF GDB, after/if
it gets decided):
	https://fedorahosted.org/fesco/ticket/858


> But does it answer your question about "ignore it"?

I have left the downstream decision to the ticket above, my already proposed
behavior (current FSF GDB state) is clearly wrong for users.


Thanks,
Jan

Re: [RFA] ignore PYTHONHOME environment variable.

[Joel Brobecker]

> Yes, user has requested the same feature.  It is rather a decision what
> should be general behavior across applications linking with libpython (not
> just for GDB).
[...]
> Therefore I have filed distro-wide (sure to be only FYI for FSF GDB, after/if
> it gets decided):
> 	https://fedorahosted.org/fesco/ticket/858

Yeah - perhaps it is a bad idea to ignore PYTHONPATH just on our own.
So, do you confirm this topic is on hold for the moment?

-- 
Joel

Re: [RFA] ignore PYTHONHOME environment variable.

[Jan Kratochvil]

On Tue, 29 May 2012 16:54:02 +0200, Joel Brobecker wrote:
> > Therefore I have filed distro-wide (sure to be only FYI for FSF GDB, after/if
> > it gets decided):
> > 	https://fedorahosted.org/fesco/ticket/858
> 
> Yeah - perhaps it is a bad idea to ignore PYTHONPATH just on our own.
> So, do you confirm this topic is on hold for the moment?

It is still being discussed, feel free to follow-up there, so far the feedback
(even off this ticket) is that just FSF GDB behaves right.


Regards,
Jan

Re: [RFA] ignore PYTHONHOME environment variable.

[Jan Kratochvil]

On Tue, 29 May 2012 16:54:02 +0200, Joel Brobecker wrote:
> > Therefore I have filed distro-wide (sure to be only FYI for FSF GDB, after/if
> > it gets decided):
> > 	https://fedorahosted.org/fesco/ticket/858
> 
> Yeah - perhaps it is a bad idea to ignore PYTHONPATH just on our own.

So in the end Python upstream has decided the current behavior (not to do 
anything special at the Python-embedded apps side) is right:

http://bugs.python.org/issue14956#msg161959
# No it shouldn't.  As mentioned in the Fedora thread you linked, this is no 
# different than the user setting LD_LIBRARY_PATH to something that screws up
# a system installed program.


Regards,
Jan