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

Ответ 1

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

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

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

В моем случае я набрал python, который был на моем $PATH в /usr/local/bin/python. Но bash все еще использовал старое расположение кэша /usr/bin/python. Итак, был выдан старый исполняемый файл, но новый путь был предоставлен python в sys.argv[0]. Это означает, что старый исполняемый файл запущен, но новое значение sys.executable вызвало загрузку всех неправильных модулей (включая модуль 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 "<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

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

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

Ответ 2

Согласно 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 в консоли, и если он преуспеет, проверьте, загружен ли он с того же пути.

Ответ 3

Переустановите 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"

Ответ 4

У меня была такая же проблема, она успешно исправлена ​​просто заменой файла _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, который вы только что нашли.

Ответ 5

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

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

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

• brew reinstall macvim

Ответ 6

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

Ответ 7

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

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

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

sudo rm -rf ~/anaconda 
update PATH variable

Ответ 11

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

Ответ 12

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