This only applies when os.name == 'posix'.

Running an un-installed build of Python with the -S
option causes the directory containing the standard
dynamically-built modules not to be placed on sys.path.

The build/lib.<platform>-<version>/ directory
containing those modules is added to sys.path by
site.py rather than getpath.c, even though those
modules are needed.  This includes many modules on most
Unix systems:

array          dbm            math      regex     termios
audioop        dl             md5       resource  _testcapi
binascii       errno          mmap      rgbimg    time
bsddb          fcntl          mpz       rotor     timing
cmath          fpectl         nis       select    _tkinter
_codecs        gdbm           operator  sha      
unicodedata
cPickle        grp            parser    _socket   _weakref
crypt          _hotshot       pcre      _ssl     
xreadlines
cStringIO      _hotshot       pwd       strop     zlib
_curses_panel  linuxaudiodev  pyexpat   struct
_curses        _locale        readline  syslog

Perhaps the best way to fix this is to add the
equivalent code to getpath.c.  The relevant stanza in
site.py is headed by a comment saying "especially for
Guido".

We have lived this long without changing this that I don't think this needs fixing.  Requiring the use of site.py when running from a build from a repository checkout seems totally reasonable to me.

Note that this does cause incompatibility between development copies and
installed copies:

$ python -S -c "import itertools; print itertools"
<module 'itertools' from ...>

$ ./python -S -c "import itertools; print itertools"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named itertools

If we think once can reliably add the directory based purely on whether
it starts with "build/lib.", and then potentially check for a suffix of
"-pydebug" if we are in a debug build, I will support adding this to
getpath.c to ditch the distutils import used by site.py.

On Thu, Sep 18, 2008 at 6:58 PM, Brett Cannon <report@bugs.python.org> wrote:
>
> Brett Cannon <brett@python.org> added the comment:
>
> If we think once can reliably add the directory based purely on whether
> it starts with "build/lib.", and then potentially check for a suffix of
> "-pydebug" if we are in a debug build,

... and if there is more than one match in the build directory, either
error out or choose one of the directories somehow. I guess the real
question is how often to people actually have multiple versions of
their built libraries in build/.

r83988 does really fix this issue in python 3.2, 8 years later, yeah!

Ooops, I didn't notice that Antoine did already updated this issue. Restore the resolution as duplicate since the superseder field is set.