tl;dr: Fix this issue by doing one of the following:
- type
hash -r python
, OR
- log out and log in.
EDIT: An answer to my related question makes it clear what's happening here. When you install a new version of python, you may need to run hash -r python
to tell bash to reset the "cached" location to the python
executable.
In my case, I was typing python
, which was on my $PATH
at /usr/local/bin/python
. But bash
was still using the old cache location /usr/bin/python
. So, the old executable was called, but the new path was provided to python in sys.argv[0]
. This means that the old executable was running, but the new sys.executable
value caused all the wrong modules to get loaded (including the io
module).
I'm having the same problem. I installed python 2.7.11 via an installer from Python.org. Strangely, the issue seems to be related to some subtle difference between how OSX launches python
when I invoke it from the shell using the full path vs. using just the word python
.
So, for me, this works (invoking python via the full path /usr/local/bin/python
):
$ which python
/usr/local/bin/python
$ /usr/local/bin/python -c "import io"
$
... but this doesn't:
$ python -c "import io"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/io.py", line 51, in <module>
import _io
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so, 2): Symbol not found: __PyCodecInfo_GetIncrementalDecoder
Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
Expected in: flat namespace
in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
So, as a workaround, you can try doing the same thing.
Elsewhere, I've posted a separate question about this puzzling behavior. Maybe somehow merely calling python
invokes some strange mix of the 2.7.11 executable with the 2.7.10 dylibs??
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…