os x 10.6.8 — невозможно вводить символы, отличные от ASCII/UTF-8 (например: å, ä, ö) в интерактивном режиме Python

Похоже, проблема здесь в том, что python.org Python ожидает настоящего readline и не доволен заменой libedit, которую предоставляет Apple.

См. документацию для readline в PyPI для объяснения проблемы.

Вы можете исправить это следующим образом:

sudo /path/to/easy_install readline

Обратите внимание, что readline — это одна из немногих вещей, которые не могут быть правильно установлены с помощью pip, поэтому вам придется использовать easy_install (или делать это вручную).

Установщики python.org 2.x не поставляются с easy_install. Установите его, следуя инструкциям на странице setuptools.

Кроме того, имейте в виду, что в некоторых случаях вы можете получить Apple-python easy_install как в /usr/local/bin, так и в /usr/bin, что означает, что вы не можете быть уверены, что /usr/local/bin/easy_install получит версию python.org, поэтому явно используйте easy_install-X.Y.

И даже это не поможет, если вы используете python.org (или другую) установку версии XY, которую Apple уже предоставила вам. /usr/local/bin/easy_install-2.7 вполне может принадлежать Apple (как на машине с 10.8.2, за которой я сейчас сижу). Единственный способ быть в безопасности — проверить строку shebang и посмотреть, какой интерпретатор Python она использует.

Или, проще говоря, просто не устанавливайте python-XY, если Apple уже предоставила вам его. Серьезно, по всему SO есть сотни вопросов от людей, которые сделали это и имеют проблемы, и всех их можно было бы избежать, просто используя сборку Apple. Раньше Apple поставляла сломанный, неполный и/или крайне устаревший Python, но начиная с версии 10.5 или 10.6 они выпускали работающие, полные, достаточно свежие версии с такими дополнениями, как easy_install и PyObjC.

Поскольку вы используете 2.7.3, которого нет в 10.6, вы, очевидно, установили какой-то сторонний Python.

Если вы посмотрите на страницу загрузки для Python 2.7.3 для "Mac Установщик OS X 64-bit/32-bit x86-64/i386 (2.7.3) для Mac OS X 10.6 и 10,7-дюймовый установщик, он говорит:

Вам может понадобиться обновленная установка Tcl/Tk для запуска IDLE или использования Tkinter, инструкции см. в примечании 2.

В примечании 2:

Здесь есть важная информация об IDLE, Tkinter и Tcl/Tk в Mac OS X. Кроме того, в Mac OS X 10.6, если вам нужно создать модули расширения C с установленным 32-разрядным Python, вам потребуется Apple Xcode 3, а не 4. 64-разрядный/32-разрядный Python может использовать Xcode 3 или Xcode 4.

Если вы перейдете по ссылке, это объяснит проблемы с версией Tcl/Tk, которая пришел с 10.6. Обратите внимание, что на приведенной ниже диаграмме Apple 8.5.7 особо не рекомендуется.

Если вы хотите использовать IDLE с не-Apple Python на 10.6, в таблице рекомендуется установить ActiveTcl 8.5.13.

На странице не объясняется точно, в чем заключаются проблемы, но, если я правильно помню, Tk от Apple аварийно завершал работу всякий раз, когда TkInter получал не-ASCII-символ при определенных обстоятельствах, и лучший обходной путь, который они могли придумать для IDLE, состоял в том, чтобы просто отклонить эти символы, именно так, как вы видите.

Если вы используете другой Python 2.7.3 (Enthought, ActiveState, Homebrew, MacPorts, собранный вручную и т. д.), у них в основном нет подробной документации по этой проблеме, но то же исправление, вероятно, будет работать.

Я считаю, что 10.6 — это также время, когда Apple начала поставлять достаточно современные версии Python и рабочий IDLE, поэтому вы можете просто использовать его вместо стороннего Python. (Однако я могу ошибаться, и это может быть верно только для 10.7 и более поздних версий.)

У меня почти такие же проблемы обсуждаются в "Как определить/объявить кодовые точки utf-8 для специальных турецких символов (не-ascii), чтобы использовать их в качестве стандартной кодировки utf-8?". Насколько я понял, проблема связана с неэффективными определениями в юникоде и утф-8. Объявления в юникоде и utf-8 основаны на отображении шрифтов для символов (расширяющие акцентные, нестандартные). Это могло бы быть удовлетворительным в старые времена, но сегодняшние требования к программированию намного опережают стандарты ansi на основе ascii, а текущие объявления cahrcode для многих языков (имеющие расширенные алфавиты кодировки на основе ascii) имеют проблемы с обработкой кодирования, преобразования и тестирования. Вы можете найти больше деталей в примечаниях под моим вопросом. utf-8 был разработан без версий, но я боюсь, что неанглийские латинские алфавиты должны быть повторно объявлены в новой версии utf-8, чтобы предоставить полный диапазон для каждого алфавита, сохраняя при этом одни и те же шрифты для одних и тех же символов. В моей теории у каждого алфавита будет свой собственный A с относительно разными кодами символов и кодовыми точками, но все A (s) будут указывать на один и тот же код шрифта. Таким образом, при отображении A на любом языке с использованием кода шрифта каждый A будет меньше любого символа в его алфавите, но ascii z никогда не будет меньше, чем ŞşÇçÖö или любой символ с акцентом....