Случайно услышал рассказ одного коллеги другому о том, что в скриптовых языках все очень клево и удобно. Рассказчик пропагандировал perl, как что-то очень крутое, простое и понятное.
Не удержался и встрял, сказав, что python попонятнее будет, а возможностей предоставляет совсем не меньше.
Дальше меня спросили, как в python обстоят дела с регулярными выражениями, и в результате пришли мы к такой задаче:

Есть строка, необходимо вывести все слова в ней, которые встречаются N раз.

Задачка конечно совсем тривиальная и написание решения занимает считаные минуты, но этот тупняк поглотил всех как минимум на несколько часов. Если вы поддаетесь тупнячкам, то прошу пожаловать подкат

Проблема

Для работы с базой данных MSSQL Server 2005 в кодировке UTF-16(UCS2) я использую скрипт, написанный на python. Этот скрипт использует для работы с базой данных следующий набор инструментов:

• unixODBC
• FreeTDS
• pyodbc
• sqlachemy

И тут появилась трудность: при получении строковых данных из базы (поля nvarchar, ntext) неправильно обрабатывается юникод.
Как выяснилось, установленный у меня питон был собран с UCS4 юникодом. Методы получения типа юникода в сборке python хорошо описаны в данном вопросе на stackoverflow. Т.е, если выполнить следующую строчку в терминале:

python -c "import sys;print 'UCS4' if sys.maxunicode > 65536 else 'UCS2'"

то мы получаем версию сборки юникода для python.В моем случае это было UCS4. Что это за собой тянет:

1. unixODBC вызывая соответствующие функции работы с базой данных с аппендиксом W (например, SQLExecDirectW()), получает результаты. в которых один символ текста занимает 2 байта(UCS2)
2. pyodbc получает результаты от ODBC-драйвера, и в свою очередь сохраняет результаты в переменную с типом unicode
3. Таким образом 1 символ результата, по мнению pyodbc, составляет 4 байта(UCS4). Именно так и сохраняется результат. полученный из ODBC-драйвера.

Драйвер возвращает данные, в которых символ занимает 2 байта, а pyodbc переделывает эти данные так, что символ занимает 4 байта. Все бы хорошо, если бы было какое-либо преобразование, но данные просто сохраняются как массив байтов в переменную с типом unicode, что несет неприятные последствия: символ результата по-сути содержит 2 символа того результата, который вернул ODBC-драйвер.