Проблема добавления поддержки 3го питона в библиотеки есть, но не так уж все и плохо. Новые библиотеки достаточно просто писать так, чтоб они поддерживали и 2.х, и 3.х без всяких утилит 2to3.
«Хаки вроде sys.exc_info()[1], для обхода синтактических различий, хаки конвертирования литералов во время исполнения для совместимости с 2.х и 3.x» — эти хаки не нужны, если не поддерживать 2.5. А его поддерживать imho не нужно, т.к. в него даже security-обновлений не будет больше, да и в хоть как-то актуальных ОС его нет (в предыдущем долгоиграющем red hat 2.4, а не 2.5, и это совсем другая история).
Очень многие «большие» старые библиотеки уже портированы (вот это бывает трудно, да). C-расширения можно писать не напрямую, а через ctypes, cython и тд — поддержка 3го питона тогда в них появляется более-менее автоматически. Писать C-расширения на C все равно не очень хорошо, т.к. под pypy они если и заведутся, то по-тормозному.
Армин умный чувак и в статье много хороших мыслей, но у Армина достаточно специфичные требования (компилятор шаблонов в питоний код, например), да и статья не новая, не стоит ее уж очень близко к сердцу принимать.
Я сейчас посчитал, у меня 8 штук своих open-source библиотек, которые под 2.х и 3.х работают из одного исходного кода (втч с C расширениями), + несколько чужих библиотек портировал (или помогал портировать). Писать новый код, который и там, и там работает — совсем не сложно, это просто дело привычки, и выглядит он ничем не хуже, чем код для 2.х (а часто даже и лучше, т.к. приучаешься к __future__ импортам и более новым языковым конструкциям). Портировать — сложнее, особенно большие, старые или трюкачистые, но тоже вполне реально (nltk так и не допортировал окончательно, но там большая часть тестов уже проходит, и пара глав из nltk book работает, жду помощи из-за границы теперь).
Вот чем баг-трекер гитхаба плох, так это тем, что с ним не получится следовать совету «Закрывайте исправленные тикеты» — тикет там может закрыть или админ репозитория, или открывший человек. Можно, конечно, в комментариях писать «закройте», но это все равно неудобно. Та же джанга отчасти из-за этого баг-трекер на github не использует, хотя код на гитхаб переехал.
Мне линод тоже нравится, и проблем с ним не было. Но у hetzner ресурсов сильно больше за те же $. В линоде за 60$ VPS с 1.5 RAM и 60Gb диска, в хетцнере за 60$ выделенный сервер с 32GB RAM и 2x3TB raid — искушение велико.
У нас «code review» ручной (просто коммиты друг друга читаем регулярно), пишут все неплохо, не вижу смысла в каких-то дополнительных механических методах, они разработку в небольшой команде не ускорят imho.
Насчет ошибок — тесты пишем, не то чтобы фанатики, но покрытие процентов 80 есть, тесты прогоняются автоматом при каждой выкладке на сервер (да и локально гоняем их), вот это помогает.
Делать начали в марте; первое время делали вдвоем с верстальщицей, потом еще человек подключился. К апрелю, в принципе, пользоваться сайтом с точки зрения пользователя было можно (24 марта — первая бронь), но многих вещей не хватало (вроде смс, входа через фейсбук и панели для ресторанов); мы публично тогда не запускались, но более-менее рабочий сайт упростил и ускорил заключение соглашений с ресторанами (а смысл в сервисе бронирования без них).
Ну и не стоит говорить о разработке в прошедшем времени, все самое интересное только начинается, останавливаться на достигнутом мы не намерены :)
Баг-репорт и/или pull request про это в любой из проектов с радостью приму! Мне кстати комрады, с кем работаю (@obiwanus, например), тоже часто пишут, что вот именно с пробелами вокруг аргументов не всегда последователен :) pep8 уважаю, невнимательность стараюсь исправлять.
Как раз об этом в следующей статье написать хотел, пол-стать уже готово) Про django-fab-deploy уже писал, но там поменялось многое, и несколько тонкостей есть. Сайт — на дебиане + апаче + mod_wsgi; деплоим fab push:migrate,pip_update из консоли; ветки используем, но меня не совсем устраивает, как (ветки production и testing для продакшн- и тестового сервера + ветки под фичи без спец. значений); сейчас нагрузка не очень большая, запустились недавно и рекламы никакой не было пока; запас прочности есть; сервер — hetzner 4S за 60$ в месяц (с линода перелезли) — дофига ресурсов за такие деньги.
Из «больших» на джанге можно еще, кстати, pinterest отметить — в январе 2012 у него больше трафика было, чем у LinkedIn, YouTube или Google+ — вот уж действительно большой сайт на джанге :) Пишут, что используют «patched django», а что именно patched — не отвечают :)
У нас как-то так получается, что в основном не заменяем части джанги полностью, а надстраиваем. В шаблонах/формах — widget-tweaks, в моделях — model-utils, в тестах — factory-boy и django-webtest, обработка ошибок — sentry как логгер и т.д. Некоторые части не используем в принципе (contrib.comments, свои виджеты для форм, form preview, form wizard, flatpages, humanize, serialization, sites), но в остальном обычная джанга — так код понятнее и проще поддерживать (т.к. опыт с джангой есть у многих).
в django-pjax, кстати, подход, аналогичный декоратору ajax_request — мне кажется, наследник TemplateResponse все-таки решает задачу лучше (меньше кода + более гибко).
вроде проще некуда, кастомные атрибут скопипастить можно)
В django-floppyforms хорошо то, что вся верстка в шаблонах, а не в питоне. Но с django-floppyforms все равно для изменения стандартного поведения рендеринга (== прикручивания верстки) нужно питоний код трогать и еще один шаблон определять, в отличие от django-widget-tweaks.
Не понял, о чем статья, что именно понимается под «компьютерной лингвистикой», и о каком тупике идет речь (наоборот же, сейчас подъем скорее и заметные проекты вроде IBM Watson или Siri, чего в предыдущий десяток лет не было). То, что упрощенные средства решения задач имеют ограничения — это понятно, но почему считать «компьютерную лингвистику» наукой только об упрощенных средствах решения? Одно строится на основе другого, сначала разрабатываются базовые инструменты и подходы, потом более продвинутые.
Про количество фреймворков (и другого кода) — чушь. По ощущениям (когда несколько лет назад с php на питон перешел) — количество готового кода и экосистема у того же питона уж получше, чем в php.
Я прекрасно знаю, как это обходится, и как с toJSON проблему решили (точно так же).
Это не отменяет того факта, что проблема есть (иначе зачем эти костыли), решают ее в основном постфактум (когда все уже сломалось), оставляя код, работающий на предыдущих версиях, сломанным. Пример: js от iframe-приложений вконтакте еще вроде в прошлом году использовал библиотеку (не помню, какую), которая в итоге переопределяла метод toJSON. И из-за этого мутулз не работал с iframe-приложениями вконтакте, даже несмотря на то, что в самом мутулз проверка на undefined была.
Чтоб обезопасить себя и делать надежные библиотеки, нужно, получается, или обладать телепатическими способностями и не переопределять методы, которые потом войдут в стандарт, или каждый метод проверять на undefined и молиться, что нативная версия будет делать то же самое, что и наша (== тоже телепатические способности). Пример — Function.bind из мутулз: нативная версия имеет другой интерфейс, нежели та, которая в мутулз реализована была, и никакие проверки на undefined тут не помогут опять, код починить можно только постфактум, старые версии оставляя сломанными.
И это все при том, что в питоне это было бы такой уж и большой проблемой (мы там обычно имеем контроль как над интерпретатором, так и над кодом). В js проблема серьезнее, т.к. интерпретатор обновляется постоянно, и контроля над ним разработчик не имеет. Из-за этого имеет чертову кучу сломанного js на старых сайтах, разные неработающие демки и тд.
«Хаки вроде sys.exc_info()[1], для обхода синтактических различий, хаки конвертирования литералов во время исполнения для совместимости с 2.х и 3.x» — эти хаки не нужны, если не поддерживать 2.5. А его поддерживать imho не нужно, т.к. в него даже security-обновлений не будет больше, да и в хоть как-то актуальных ОС его нет (в предыдущем долгоиграющем red hat 2.4, а не 2.5, и это совсем другая история).
Очень многие «большие» старые библиотеки уже портированы (вот это бывает трудно, да). C-расширения можно писать не напрямую, а через ctypes, cython и тд — поддержка 3го питона тогда в них появляется более-менее автоматически. Писать C-расширения на C все равно не очень хорошо, т.к. под pypy они если и заведутся, то по-тормозному.
Армин умный чувак и в статье много хороших мыслей, но у Армина достаточно специфичные требования (компилятор шаблонов в питоний код, например), да и статья не новая, не стоит ее уж очень близко к сердцу принимать.
Я сейчас посчитал, у меня 8 штук своих open-source библиотек, которые под 2.х и 3.х работают из одного исходного кода (втч с C расширениями), + несколько чужих библиотек портировал (или помогал портировать). Писать новый код, который и там, и там работает — совсем не сложно, это просто дело привычки, и выглядит он ничем не хуже, чем код для 2.х (а часто даже и лучше, т.к. приучаешься к __future__ импортам и более новым языковым конструкциям). Портировать — сложнее, особенно большие, старые или трюкачистые, но тоже вполне реально (nltk так и не допортировал окончательно, но там большая часть тестов уже проходит, и пара глав из nltk book работает, жду помощи из-за границы теперь).
Насчет ошибок — тесты пишем, не то чтобы фанатики, но покрытие процентов 80 есть, тесты прогоняются автоматом при каждой выкладке на сервер (да и локально гоняем их), вот это помогает.
Ну и не стоит говорить о разработке в прошедшем времени, все самое интересное только начинается, останавливаться на достигнутом мы не намерены :)
Из «больших» на джанге можно еще, кстати, pinterest отметить — в январе 2012 у него больше трафика было, чем у LinkedIn, YouTube или Google+ — вот уж действительно большой сайт на джанге :) Пишут, что используют «patched django», а что именно patched — не отвечают :)
У нас как-то так получается, что в основном не заменяем части джанги полностью, а надстраиваем. В шаблонах/формах — widget-tweaks, в моделях — model-utils, в тестах — factory-boy и django-webtest, обработка ошибок — sentry как логгер и т.д. Некоторые части не используем в принципе (contrib.comments, свои виджеты для форм, form preview, form wizard, flatpages, humanize, serialization, sites), но в остальном обычная джанга — так код понятнее и проще поддерживать (т.к. опыт с джангой есть у многих).
Насчет усложнения шаблонов, верстка:
превращается в
вроде проще некуда, кастомные атрибут скопипастить можно)
В django-floppyforms хорошо то, что вся верстка в шаблонах, а не в питоне. Но с django-floppyforms все равно для изменения стандартного поведения рендеринга (== прикручивания верстки) нужно питоний код трогать и еще один шаблон определять, в отличие от django-widget-tweaks.
php pear: 586 пакетов;
pypi.python.org 20000+ пакетов:
rubygems: 37000+ гемов;
cpan: 25000+ distributions.
гитхаб (видимо, % от общего числа репозиториев):
JavaScript 20%
Ruby 15%
Python 9%
Shell 8%
Java 8%
PHP 7%
По-моему тридцатикратным преимуществом php близко не пахнет.
Это не отменяет того факта, что проблема есть (иначе зачем эти костыли), решают ее в основном постфактум (когда все уже сломалось), оставляя код, работающий на предыдущих версиях, сломанным. Пример: js от iframe-приложений вконтакте еще вроде в прошлом году использовал библиотеку (не помню, какую), которая в итоге переопределяла метод toJSON. И из-за этого мутулз не работал с iframe-приложениями вконтакте, даже несмотря на то, что в самом мутулз проверка на undefined была.
Чтоб обезопасить себя и делать надежные библиотеки, нужно, получается, или обладать телепатическими способностями и не переопределять методы, которые потом войдут в стандарт, или каждый метод проверять на undefined и молиться, что нативная версия будет делать то же самое, что и наша (== тоже телепатические способности). Пример — Function.bind из мутулз: нативная версия имеет другой интерфейс, нежели та, которая в мутулз реализована была, и никакие проверки на undefined тут не помогут опять, код починить можно только постфактум, старые версии оставляя сломанными.
И это все при том, что в питоне это было бы такой уж и большой проблемой (мы там обычно имеем контроль как над интерпретатором, так и над кодом). В js проблема серьезнее, т.к. интерпретатор обновляется постоянно, и контроля над ним разработчик не имеет. Из-за этого имеет чертову кучу сломанного js на старых сайтах, разные неработающие демки и тд.