Symbol not found: __PyCodecInfo_GetIncrementalDecoder

Question

Since updating from Homebrew Python 2.7.11 (from 2.7.10) I\'m suddenly unable to test register my package on PyPi from the PyCharm IDE console.

Running (as an \"Exte

Answer 1

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 "", line 1, in 
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/io.py", line 51, in 
    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??