Здравствуйте, achmed, Вы писали:
FR>>Ну туплы в параметрах функций можно подставлять, плюс раскрытие кортежей (улучшенное в 3.0) в общем скорее в зачаточном состоянии. Ну и при желании на метаклассах и декораторах можно соорудить достаточно мощные вещи близкие к PM в функциональных языках — http://peak.telecommunity.com/PyProtocols.html
A>В PyProtocols не нашел ничего похожего на PM, плохо смотрел?
Здравствуйте, dmz, Вы писали:
dmz>Впрочем, по сравнению с бесконечным адом, которым является поддержка питоновых серваков — кто пытался поставить 2.5 и нужные пакеты на него на старую федору или центос, или кто убивал Arch установкой dmz>того-же 2.5, или приводил debian stable в debian-необвновляющася-помойка-непонятно-из-каких-веток-собранная — тот поймет...
Странный у тебя опыт... Питон вполне нормально встаёт параллельно с существующим, на Debian Etch версия 2.5 ставится без всяких проблем. Ну в крайнем случае скомпилить самому и запихать в /usr/local.
А дальше прописываешь Web-приложение в /etc/lighttpd/conf-*, и оно работает.
C>Странный у тебя опыт... Питон вполне нормально встаёт параллельно с существующим, на Debian Etch версия C>2.5 ставится без всяких проблем.
Ну на дебиане проблемы были, может не из самого питона, а из-за каких-то модулей — точно не помню. Пришлось прописать нестабильные репозитарии, и понеслось по зависимостям.
А вот федоре, центосе и arch проблемы были вполне неиллюзорные, особенно пострадал в свое время арч. Некоторое время проблем действительно нет, но только на дебиане и убунту.
C>Ну в крайнем случае скомпилить самому и запихать в /usr/local.
Ага. А еще лучше — собрать фейковое окружение, собрать там питон со всеми нужными пакетами, даром что они одни и те-же от проекта к проекту, и туда-же засунуть лайти до кучи. И запускать лайти из чрута. Работать будет — вообще везде, и ставиться парой кликов. Только лень.
C>А дальше прописываешь Web-приложение в /etc/lighttpd/conf-*, и оно работает.
Ну как бы я примерно знаю, что куда надо прописать — благо десяток питоновских проектов крутится, только вот бывают проблемы, особенно на всяких RH-образиях, которые почему-то очень любят провайдеры.
Здравствуйте, dmz, Вы писали:
C>>Странный у тебя опыт... Питон вполне нормально встаёт параллельно с существующим, на Debian Etch версия C>2.5 ставится без всяких проблем. dmz>Ну на дебиане проблемы были, может не из самого питона, а из-за каких-то модулей — точно не помню. Пришлось прописать нестабильные репозитарии, и понеслось по зависимостям.
Так кто мешал руками воткнуть нужные модули в /usr/local/lib/python? И в backport'ах их тоже не было?
dmz>А вот федоре, центосе и arch проблемы были вполне неиллюзорные, особенно пострадал в свое время арч. Некоторое время проблем действительно нет, но только на дебиане и убунту.
Вполне верю.
C>>Ну в крайнем случае скомпилить самому и запихать в /usr/local. dmz>Ага. А еще лучше — собрать фейковое окружение, собрать там питон со всеми нужными пакетами, даром что они одни и те-же от проекта к проекту, и туда-же засунуть лайти до кучи. И запускать лайти из чрута. Работать будет — вообще везде, и ставиться парой кликов. Только лень.
Ну для больших веб-приложений без проблем.
C>>А дальше прописываешь Web-приложение в /etc/lighttpd/conf-*, и оно работает. dmz>Ну как бы я примерно знаю, что куда надо прописать — благо десяток питоновских проектов крутится, только вот бывают проблемы, особенно на всяких RH-образиях, которые почему-то очень любят провайдеры.
Выбирай нормальных провайдеров На "enterprise" дистрибутивах обычно всё вообще очень древнее.
По опыту, Python-приложения у меня ставились проще всего. Следом идёт Ruby по удобству установки. Примерно на равных с ним — приложения на Java. А сложнее всего бороться с PHP.
Здравствуйте, Critical Error, Вы писали: CE>Да меня в общем то тоже удивило и огорчило, что автор языка несколько отстал развития
Угу. По-моему, Гвидо зарубил все полезные фичи с резолюцией "нет и не будет". До кучи даже анпакинг туплов выкинули (pep-3113 без слез читать невозможно)
Зато деловитым видом творится какая-то колбасня со списками-генераторами-представлениями, исключениями и прочий мелкий рефокторинг языка. А, ну да, ввели повсеместный юникод, что, в принципе, неплохо.
Здравствуйте, Mr.Cat, Вы писали:
MC>Угу. По-моему, Гвидо зарубил все полезные фичи с резолюцией "нет и не будет". До кучи даже анпакинг туплов выкинули (pep-3113 без слез читать невозможно)
Анпакинг тупл-параметров для вас полезная фича? О_о
C>Так кто мешал руками воткнуть нужные модули в /usr/local/lib/python? И в backport'ах их тоже не было?
Это был девелоперский сервер, и там я стараюсь делать так, что бы все нужные пакеты ставились apt-ом, причем, желательно, из репозитариев по умолчанию. Так что сюда же следует задать вопрос, почему мы не не собрали все пакеты с нужными версиями, не подняли свой репозитарий. Ну вот, не собрали. Это все требует времени и сил, ресурсов на это особо нет.
C>Ну для больших веб-приложений без проблем.
C>Выбирай нормальных провайдеров На "enterprise" дистрибутивах обычно всё вообще очень древнее.
Да как бы уже выбрали, называется collocation. Но почему-то некоторым клиентам хочется, что бы софт ставили на их серверы или к их провайдерам, и там выбирать особо не из чего.
C>По опыту, Python-приложения у меня ставились проще всего. Следом идёт Ruby по удобству установки. Примерно на равных с ним — приложения на Java. А сложнее всего бороться с PHP.
Ну а вот представь, что весь дистрибутив твоего приложения — это один бинарник и один конфиг, ну и секция конфига для веб-сервера, который используется как реверс-прокси. Можно даже сделать инсталлятор для любой платформы, причем это просто.
Здравствуйте, dmz, Вы писали:
dmz>Да как бы уже выбрали, называется collocation. Но почему-то некоторым клиентам хочется, что бы софт ставили на их серверы или к их провайдерам, и там выбирать особо не из чего.
Для таких клиентов можно сделать бандл, устанавливающийся в /opt.
dmz>Ну а вот представь, что весь дистрибутив твоего приложения — это один бинарник и один конфиг, ну и секция конфига для веб-сервера, который используется как реверс-прокси. Можно даже сделать инсталлятор для любой платформы, причем это просто.
Ну нафиг такое счастье. А если что-то поправить в нём нужно будет? Со скриптами всё просто.
И с зависимостями тоже что делать? Всё вкомпиливать статически?
C>Ну нафиг такое счастье. А если что-то поправить в нём нужно будет? Со скриптами всё просто.
Что значит "подправить" ? Подправлять ничего нельзя, можно только выпустить патч.
C>И с зависимостями тоже что делать? Всё вкомпиливать статически?
Если их не много, то по моему — лучший вариант. Причем, имея бинарник версии X, мы гарантируем, что он собран именно с теми библиотеками (и с теми патчами, что мы наложили, если вдруг), с которыми и у нас на стенде. Отдаем админу клиента бинарник — и он ничего не может сломать, даже если захочет.
В общем, с питоном все эти проблемы решается путем сборки своего бандла, да. Только вот что бы его сделать, надо приложить немало усилий. А так за тебя это делает линкер.
Здравствуйте, dmz, Вы писали:
C>>Ну нафиг такое счастье. А если что-то поправить в нём нужно будет? Со скриптами всё просто. dmz>Что значит "подправить" ? Подправлять ничего нельзя, можно только выпустить патч.
У меня объём приложения вместе с ресурсами — около 100Мб. Будем каждый раз новые 100Мб выкладывать? И вообще, как будем ресурсы отдавать — lighty использовать не получится, так как он только файлы понимает.
dmz>В общем, с питоном все эти проблемы решается путем сборки своего бандла, да. Только вот что бы его сделать, надо приложить немало усилий. А так за тебя это делает линкер.
Это только кажется...
Здравствуйте, dmz, Вы писали:
dmz>В общем, с питоном все эти проблемы решается путем сборки своего бандла, да. Только вот что бы его сделать, надо приложить немало усилий. А так за тебя это делает линкер.
Я с вебом (на сервере) дел практически не имел, но для десктопных приложений линкер заменяется одним дополнительным скриптом который все и собирает и если надо даже делает тестовую установку.
FR>Я с вебом (на сервере) дел практически не имел, но для десктопных приложений линкер заменяется одним дополнительным скриптом который все и собирает и если надо даже делает тестовую установку.
py2exe ? Не поручусь точно, но по-моему, на линуксе не его аналог давно забили. Плюс, питон предоставляет много средств, что бы прострелить себе голову, например динамическая загрузка.
Уф, я примерно знаю, как решать проблемы, которые возникают при развертывании питоновых приложений. В принципе, все способы уже перечислены в этом треде. Хочется сделать так, что бы решать их в принципе не приходилось. Естественно, это не единственное соображение, из-за которого с питона хочется съехать.
Конечно, на любую озвученную проблему найдется возражение. Нет средства автоматической линковки в некие бандлы? Можно сделать самим десятком способов.
Медленный (по сравнению) — а куда нам спешить, все равно все упрется в базу
Нет и не будет concurrency? Ну и что, все равно с одного сервера снимаем 1500 RPS, это 129600000 хитов в сутки, столько не бывает
Ну и так далее — могу написать еще десяток пунктов с контр-доводами.
Думаю, что в той команде, которая сложилась у нас, будет правильнее перейти на другие средства, учитывая специфику проектов.
Основное, пожалуй — по моему, время, требуемое на разработку и поддержку юнит-тестов, без которых что-то делать на языках с динамической типизацией стрёмно, начиная с какого-то момента начисто сжирает все преимущество в скорости разработки. К тому же, с теми сроками, которые у нас бывают, у разработчиков есть соблазн вообще их не писать, или писать минимально, таким образом косяки, которые неизбежно возникают в динамических языках, имеют все шансы пролезть в продакшн. Что и случается.
Здравствуйте, Mr.Cat, Вы писали:
MC>Угу. По-моему, Гвидо зарубил все полезные фичи с резолюцией "нет и не будет". До кучи даже анпакинг туплов выкинули (pep-3113 без слез читать невозможно) MC>Зато деловитым видом творится какая-то колбасня со списками-генераторами-представлениями, исключениями и прочий мелкий рефокторинг языка. А, ну да, ввели повсеместный юникод, что, в принципе, неплохо.
Ну по моему почти все нововведения питона 3000 полезны, ну или по крайней мере являются логическим продолжением (завершением) развития питона в том виде в каком мы его знаем. Будь я автором языка, я бы тоже пошел именно этим путем. А вот по части новых фич навроде паттерн-матчинга, оптимизации хвостовой рекурсии или поддержки конкурентности я думаю так: автор наиграется с генераторами и итераторами и таки займется расширением синтаксиса. Ведь от этого никуда не денешься...
Здравствуйте, dmz, Вы писали:
dmz>Нет и не будет concurrency? Ну и что, все равно с одного сервера снимаем 1500 RPS, это 129600000 хитов в сутки, столько не бывает
Вот кстати очень интересный проект, привносящий новые фичи по поддержке конкурентности в питон: http://www.stackless.com/
Проект существует уже давно и используется в основном в играх, например в известной онлайновой игре EVE Online. Там сервер написан с применением stackless.
Здравствуйте, Critical Error, Вы писали:
CE>Да и не особо страшен этот GIL. Например если ваш тред висит и ожидает предположим сокет, то замедления производительности не будет. В остальных случаях многопоточная программа будет выполняться как однопоточная, без замедления по крайней мере. Модуль multiprocessing нужен для тех случаев когда питон обрабатывает кучу данных и очень надо чтобы оно работало быстрее. Но если такая ситуация приключилась с вами, то скорее всего не верно выбран инструмент... на сишке такое писать надобно.
я использовал хаскел для организации потоков, в каждом из которых выпоонялся сишный код. как инструмент лёгкого создания потоков и организации связи между ними в/у язык куда удобней c/c++
Здравствуйте, FR, Вы писали:
FR>Функциональный язык конечно бы помог, но по моему на уровне не большем статистической погрешности, так как объем кода небольшой, но алгоритмическая сложность достаточно высокая.
по моим наблюдениям хаскел как раз очень хорош для описания сложных алгоритмов
metalua видел? почитай metalua-manual.pdf в http://metalua.luaforge.net/metalua-0.4.1-rc1.tgz
наиболее ФП из всех скриптовых языков, с расширяемым синтаксисом
dmz>Основное, пожалуй — по моему, время, требуемое на разработку и поддержку юнит-тестов, без которых что-то делать на языках с динамической типизацией стрёмно, начиная с какого-то момента начисто сжирает все преимущество в скорости разработки. К тому же, с теми сроками, которые у нас бывают, у разработчиков есть соблазн вообще их не писать, или писать минимально, таким образом косяки, которые неизбежно возникают в динамических языках, имеют все шансы пролезть в продакшн. Что и случается.
конечно, каждый должен самостоятельно наступить на жэти грабли. мне нравился перл лет 10 назад, когда единственной алтернативой был С++, и скриптовые языки позвояли на порядок быстрее разрабатывать программы. но — только до определённого объёма. когда дело доходит до больших программных комплексов, то ты начинаешь люить строгую типизацию как мать родную особенно если она такая мощная, как в хаскеле. строгая типизация + вывод типов — это золотой стандарт, не надо выписывать ручками все эти витиеватые типы и в то же время не чуствуешь себя сидящим на пороховой бочке. 90% ошибок отсекаются на стадии компиляции программы
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, Critical Error, Вы писали:
CE>>Да и не особо страшен этот GIL. Например если ваш тред висит и ожидает предположим сокет, то замедления производительности не будет. В остальных случаях многопоточная программа будет выполняться как однопоточная, без замедления по крайней мере. Модуль multiprocessing нужен для тех случаев когда питон обрабатывает кучу данных и очень надо чтобы оно работало быстрее. Но если такая ситуация приключилась с вами, то скорее всего не верно выбран инструмент... на сишке такое писать надобно.
BZ>я использовал хаскел для организации потоков, в каждом из которых выпоонялся сишный код. как инструмент лёгкого создания потоков и организации связи между ними в/у язык куда удобней c/c++
А есть какие-нибудь стоящие линки про организацию потоков в хаскеле?
(до соотв. в главы в Real World Haskell ещё не добрался )
На "enterprise" дистрибутивах обычно всё вообще очень древнее.
особенно если она такая мощная, как в хаскеле. строгая типизация + вывод типов — это золотой стандарт, не надо выписывать ручками все эти витиеватые типы и в то же время не чуствуешь себя сидящим на пороховой бочке. 90% ошибок отсекаются на стадии компиляции программы
