Символ не найден: __PyCodecInfo_GetIncrementalDecoder

tl; dr: исправить эту проблему, выполнив одно из следующих действий:

• type hash -r python , OR
• выйти из системы и войти в систему.

EDIT: Ответ на мой связанный вопрос дает понять, что здесь происходит. Когда вы устанавливаете новую версию python, вам может потребоваться запустить hash -r python чтобы сообщить bash о сбросе «кэшированного» местоположения в исполняемый файл python .

В моем случае я набирал python , который был на моем $PATH в /usr/local/bin/python . Но bash все еще использовал старое расположение кэша /usr/bin/python . Таким образом, был sys.argv[0] старый исполняемый файл, но новый путь был предоставлен python в sys.argv[0] . Это означает, что старый исполняемый файл запущен, но новое значение sys.executable привело к загрузке всех неправильных модhive (включая модуль io ).

У меня такая же проблема. Я установил python 2.7.11 через установщик с Python.org. Как ни странно, проблема, похоже, связана с некоторой тонкой разницей между тем, как OSX запускает python когда я вызываю его из оболочки, используя полный путь против использования только слова python .

Итак, для меня это работает (вызов python через полный путь /usr/local/bin/python ):

 $ which python /usr/local/bin/python $ /usr/local/bin/python -c "import io" $ 

… но это не так:

 $ 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 

Итак, в качестве обходного пути вы можете попробовать сделать то же самое.

В другом месте я опубликовал отдельный вопрос об этом загадочном поведении. Может быть, почему-то просто вызов python вызывает странное сочетание версии 2.7.11 с 2.7.10 dylibs?

Согласно https://github.com/klen/python-mode/issues/634 :

У меня была такая же проблема, но она исправлена. В моем случае я скомпилировал python и vim с homebrew, когда PYTHON_PATH был указан и установлен в одну из моих сред dev, где у меня также были некоторые библиотеки, включая io. Обходной путь был прост: откройте новый терминал, убедитесь, что у вас нет пользовательского PYTHON_PATH, удалите python, удалите vim. Переустановите их оба.

а также

Задача решена.

Culprit – это обновление от python 2.7.10 до 2.7.11.

Если вы используете управление пакетами conda, просто запустите «conda install python = 2.7.10», решив эту проблему.

Однако это не приводит к первопричине. Поскольку это происходит с _io , это выглядит как ошибка в python 2.7.11 (маловероятно, что в этом случае будет крик мирового масштаба и быстрое исправление, если это было так) или некорректная ошибка упаковки или версии, особенно с версией homebrew (и, возможно, некоторые связанные тоже).

Попробуйте import _io в консоль, и если это удастся, проверьте, загружен ли он с того же пути.

Переустановите python.

 brew unlink python && brew reinstall python 

Защитить путь

 export PYTHONPATH=$PYTHONPATH:/usr/local/bin/ 

BACKUP и изменить порядок файлов “paths”.

 sudo nano /etc/paths 

Кажется, порядок путей, для правильного запуска python. В моем случае результатом был:

 #sudo nano /etc/paths /usr/bin /usr/local/bin /bin /usr/sbin /sbin 

На моем mac путь такой.

 $ which python /usr/local/bin/python 

Теперь я могу запустить оба:

 $ /usr/local/bin/python -c "import io" $ python -c "import io" 

У меня была такая же проблема, она успешно исправлена ​​просто заменой файла _io.so.

 sudo find / -name _io.so 

скопируйте путь к файлу _io.so который НЕ принадлежит python-2.7.11. Например, скопируйте путь _io.so, который находится под python-2.7.5: /usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib- dynload / _io.so

Замените файл /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so с указанным _io.so .

Это случилось со мной и в MacVim. Я решил это, убедившись :python print(sys.path) использует систему Python (например, /Library/Python/2.7/... )

Поскольку я установил MacVim через Homebrew, я просто сделал это:

1. Создайте новую оболочку, в which python -> /usr/bin/python . Для моего случая мне нужно было удалить строку pyenv из моего .bash_profile . Если вы установили Python через Homebrew, возможно, вам захочется brew unlink python первый раз на brew unlink python

2. brew reinstall macvim

Еще одно быстрое обходное решение, если вы не против придерживаться Python 2.7.10, – это указать путь к исполняемому файлу интерпретатора Python, который будет использоваться для virtualenv. На OSX этот путь обычно /usr/bin/python :

 virtualenv venv --python=/usr/bin/python 

Невозможно добавить комментарий (?), Так что это просто для того, чтобы разделить мой exp., Downgrade to 2.7.10 works fr me.

Если ваша проблема вызвана anaconda , нет необходимости удалять каталог //anaconda .

Просто откройте свой файл ~/.bash_profile , найдите строку

 export PATH="//anaconda/bin:$PATH 

и прокомментируйте это, затем перезапустите сеанс терминала.

Это произошло, когда я уже пытался создать venv в папке и ошибочно пытался инициализировать второй! Поэтому я просто удалил каталог venv и перезапустил команду. Скорее всего, это не ответ на это решение, но поиск моей ошибки привел меня сюда, так что это может помочь некоторым другим, кто застрял.

Я получил эту ошибку после неудачной загрузки NLTK, мне нужно было удалить anaconda:

 sudo rm -rf ~/anaconda update PATH variable 

Я решил эту проблему, удалив символическую ссылку, которая была в /usr/local/bin и скопировала фактический двоичный код python, на который была указана указанная ссылка.

У меня была такая же проблема, когда я пытался использовать PyCharm. Решенный путем установки «интерпретатора python» в конфигурации проекта, чтобы указать на виртуальный env python, который я хотел использовать, который был Anaconda env. Так или иначе, на пути переводчика отсутствовала часть «анаконды» ~ /…/ anaconda /…/_ io.so. Не нужно удалять anaconda.