bromzh

Будут (возможно) пробемы с юникодом. Например, для имён моделей в 2.7 надо перегружать __unicode__, а в 3-м - __str__. Ну и не стоит ещё забывать, что http будёт слать всё в однобайтовой кодировке, что в 3-м питоне обозначается как тип bytes, а не str. Поэтому, иногда придётся делать decode.

Например, во фласке в 3-й ветке, тестовый клиент сохраняет данные в response-объекте в виде bytes, а JSON умеет только со строками работать (которые в 3-й теперь только юникод). Надо декодировать. Хотя в самом фреймворке (не в тестовом клиенте) не надо так делать, он сам декодит как надо.

Ну и почитай основные отличия веток: print теперь функция, методы словаря iteritems, iterkeys, itervalues упразднены, так как итераторы теперь используются по-умолчанию (остались только items, keys, values). Некоторые либы (в том числе urllib) поменяли структуру, так что некоторые модули надо будет импортить по-другому. Ну и так далее.

Потому что надо литературу читать. Ты объявляешь классовую переменную. Она будет общей для всех экземпляров твоего класса. И используются они, например, для хранения информации, необходимой всем экземплярам.

sqlite

ru.diveintopython.net/toc.html

Делать в 2014 году набор компонентов с привязкой к ПХП... Печальный вуз.

Просто посмотри отношение количества идиотских вопросов к общему по ПХП и, например, по питону/руби/яве на тостере.

CORS
Вкратце - на принимающем сервере надо проставить нужные заголовки. Самый главный - Access-Control-Allow-Origin. Если делаешь публичный API , то ставь значение *.

В моторе апи почти такое же, как и в pymongo. Различия описаны тут. Неужели добавить в местах обращения к базе yield from так трудно?

UPD. Извиняюсь, ошибочка вышла. yield from - это новый синтаксис для написания асинхронного кода, введённый в питон 3.3. В торнадо используется просто yield. Хотя использовать новый синтаксис в торнадо очень легко: вместо торнадовского декоратора @tornado.gen.coroutine следует оборачивать методы в декоратор @asyncio.coroutine, вместо yield писать yield from и надо настроить торнадовский IOLoop на новый IOLoop из модуля asyncio.

Как правильно рендерить html
Так же, как и всегда. Вся прелесть декоратора корутины и yield в том, что код выходит как будто написанный в привычном синхронном стиле. Просто передавай твой результат шаблону, при рендере этот результат-генератор "раскроется" во что нужно.
Однако, я не уверен, что для чата надо использовать рендер шаблонов: по-хорошему надо отправлять сообщения через вебсокеты, на клиенте принимать их и рисовать сообщения яваскриптом.

SICP

Эскобар.жпг. Оба ужасны.
Посмотри, как это реализовано в нормальных фреймворках.

Учи итераторы. В твоём случае, тебе нужен цикл while и next, чтобы получить следующий элемент.

На самом деле, SQLAlchemy делится на 2 части: работа с БД (то, что ты хочешь) и отдельно ОРМ (который, естественно, медленнее, чем работа напрямую с БД).
Так вот, если не нужно ОРМ - не используй. Захочешь использовать модели - пожалуйста. При этом, тебе не потребуется менять библиотеки и переписывать весь код. Плюс, единообразие при работе с любыми БД.

UPD
Тут неправду пишут, что использование ОРМ всегда лучше. ОРМ всегда медленнее, нежели работа напрямую. Плюс, ты не всегда сможешь выразить на языке ОРМ то, что нужно.
На хабре часто упоминается, что для простых ненагруженных вещей люди используют JPA ORM (это для java). Когда нагрузки возрастают, переходят на "прямые" запросы. Вот только фишка в том, что эти запросы обычно описываются в неком унифицированном виде (на неком специальном варианте SQL). Таким образом, и без использования ОРМ можно не привязываться к конкретной СУБД.
Так вот алхимия как раз-таки позволяет использовать как унифицированный интерфейс для работы с БД без ОРМ (это sqlalchemy core), так и строить поверх него отображения на модели (sqlalchemy orm).