If you install python in a directory whose path contains a colon sys.path 
will be wrong, the installation directory will be split into two strings and 
both of them are added to sys.path.

The following session demonstrates the problem:

bump:~/src/python/:colon bob$ ./python.exe -c "import sys; print 
sys.path"
'import site' failed; use -v for traceback
['', '/usr/local/lib/python25.zip', '/Users/bob/src/python/', 'colon/../
Lib/', '/Users/bob/src/python/', 'colon/../Lib/plat-darwin', '/Users/bob/
src/python/', 'colon/../Lib/plat-mac', '/Users/bob/src/python/', 'colon/../
Lib/plat-mac/lib-scriptpackages', '/Users/bob/src/python/', 'colon/../
Lib/lib-tk', '/Users/bob/src/python/', 'colon/Modules']

Logged In: YES 
user_id=849994

I don't know if something can be done here. A possibility
would be, if one path segment doesn't exist, add the colon
and the next segment and try again. Martin, do you have an
opinion?

Logged In: YES 
user_id=21627

I think this can be fixed. sys.prefix should be treated as
unspittable when constructing sys.path, i.e. sys.prefix
should be inserted only after the colon-splitting has been done.

Not sure what the best way to implement that would be,
though, so unassigning.

Logged In: YES 
user_id=4771

Internally, CPython sets up its path using a single
':'-separated string.  I have no clue how, on Posix, you are
supposed to use paths containing ':' in environment variables
like $PATH - escape the colons somehow?

If there is some escape mechanism, we could support it,
both as an internal way to fix the present issue, and
directly in parsing PYTHONPATH.  If there is no such
mechanism, then I can only conclude that having colons in
paths will make many other things unhappy, not just Python.

Logged In: YES 
user_id=21627

The issue is not with environment variables at all; they
play no role in this bug report. There is no convention for
an escape mechanism in environment variables, and we should
not introduce one, but again, this report is not about
environment variables.

Logged In: YES 
user_id=580910

One way to fix this to redefine Py_GetPath to return some kind of array 
instead string that is formatted like PYTHONPATH. 

Another option is returning a string where path elements are seperated by 
NUL bytes (with two NUL bytes at the end to make it possible to find the end 
of the path).  A problem with this is that this would make it impossible to 
have empty strings in your PYTHONPATH (such as 'somedir::otherdir').

Both options have the disadvantage that they change a public interface 
(embedders can reimplement Py_GetPath to get full control over the 
construction of sys.path).

BTW. This bug was found by a user of py2app, a py2exe-like tool for macosx. 
A user of his application complained that the application didn't run when it 
was stored in a directory with colons in its name. 

This is also proving to be a problem in various places for applications
embedding Python 2.5 on Linux. For example, my EventScripts plugin
embeds Python into Counter-Strike: Source game servers. It's not
uncommon at all for these servers to use a colon in their path names, as
rental companies will often assign the directories as
myuser/IPADDRESS:PORT/cstrike. For embedding Python we have some tricks
that allow us to bypass this sometimes, but it is rather inconvenient.

In addition to sys.path, I haven't looked into it deeply, but I believe
the codecs search path also seems to get confused when the local
directory has a colon somewhere in it.

Please consider revitalizing this bug, if possible. Thanks for
considering it.

Autoconf will not even generate a Makefile that will run with a prefix
of ``/tmp/\:colon`` so closing as out of date since their is a more
fundamental toolchain issue outside of our control.