The inherent behaviour of python installations (local or global) is such that it expects to source system wide modules from the global python installation. 

There is no non hacky way to solve this problem.

The idea of local installations is that they should be independent of system-wide builds. Python's behaviour contradicts this condition.

In cases where users on clusters need to maintain their own python installations such that these installations are independent of uncontrollable cluster variables, python will break on a regular basis as it tries to import modules from the system wide sources which were compiled on a similar python version but with different parameters.

Why was this express decision made to include this path in the python development tree? 

How can this be resolved without hacking site.py?

I can't understand what's your problem.

> The inherent behaviour of python installations (local or global) is such that it expects to source system wide modules from the global python installation.

What local installation means?
What global installation means?
What "expects to source system wide module ..." means?

Could you give us concrete example?

If you build and install a "local python", you will be installing the library locally as well, and python will not look to the lib dir of the system installed python.  So yes, please explain your problem with more specifics.

In any case the problem of python trying to run with the wrong version of a .pyc file is solved in python3, since each version of python writes separately-named pyc files.

Perhaps the issue here is that you are installing a local version of Python with the same configured prefix as a system installed Python of the same major version.  This is a primary use of the --prefix option to the ./configure script of Python.  You should ensure that each Python x.y instance is built and installed with unique values for --prefix; that should ensure that there is no conflict among those instances with regard to their "global" file paths.  That said, there can still be conflicts with --user locations where the same user-specific paths are used by all instances of a particular Python major version.

close this issue because lack of information.