Андрей Светлов
Сейчас работаю над софтом, который - самый классический enterprise.

И насколько большой у вас коллектив, какова там текучка? Это я к тому, что строгая типизация очень желательна в таком коллективе. Хотя бы на уровне вызова функций и глобальных переменных. Да, я знаю, как это проконтролировать, но, имхо, это дурная работа, которую должен делать ЯП.

balu
Я скажу, где, имхо, нецелесообразно.

Еще мне понравилось использовать питон, как язык для простеньких встроенных DSL.

shizaJMS. Сейчас - Sonic. Apache ActiveMQ пробовали - не подошел. Тройка тормознутая, а четверка еще и глюкавая.
Смотрим потихоньку на AMQP, но непосредственной причины что-то менять прямо сейчас - нет.

balu Если считать только программистов - то десятка 4 как минимум. Точнее сказать затрудняюсь. Текучка, наверное, как и везде. Там, где требуется строгая типизация - она вводится. Декораторы дают довольно хорошую форму записи. Дурной работы не наблюдаю.

Андрей Светлов
А сервер приложений используете, или прям standalone?
Если используете, то какой? =)

Без сервера приложений. Толстый клиент и севисы.

Для сервисов наверное можно было бы что-то прикрутить, но все на самом деле решилость тривиальным монитором (следит, сколько чего запущено и балансирует нагрузку). По мере необходимости монитор докручиваем. Плюс для сервисов используется каркасная библиотека, многое унифицирующая. Так оказалось проще.

Андрей Светлов
Понятно. Спасибо.

Андрей Светлов
Дурной работы не наблюдаю

в декораторе тип выставил, а уже определенные типы все равно будут вычисляться каждый раз. А если надо зафиксировать тип переменной, тоже дополнительная возня.
А касательно большого коллектива - кто-то поленился сделать декоратор, а кто-то пихнул туда не тот тип. И вылезет все на этапе выполнения.

balu
А еще кто-то поленился юниттест написать… Со всеми проявлениями подобной лени мы боремся :)
Довольно успешно, хотя иногда и встречаются тяжелые случаи, требующие пинка от начальственного лица.
Тип переменной фиксируется через типизированный дескриптор (на самом деле важны только атрибуты классов).
Про “определенные типы все равно будут вычисляться каждый раз” - честно говоря не понял. Имеется в виду отсутствие проверки компилятором? Но покрытие юниттестами предполагает, что все будет вызвано на этапе запуска тестов. Тестируется логика, а проверка типов получается бесплатной. Запуск всех тестов перед commit и постоянно работающий buildbot вносят некоторый порядок. Если что-то ломается, быстро находится виновный. И у него вопрашают, почему не запустил тесты или не написал их.

Но общую мысль уловил, и она довольно здравая. Другое дело - мы научились неплохо обходить перечисленные трудности, а достоинств у Питона все же на порядок больше (по крайней мере в моих глазах).

Значит коллектив у вас более-менее устаканенный. Или разработки “на вчера” не так часты, когда на юнит-тесты времени нет.

Андрей Светлов
Про “определенные типы все равно будут вычисляться каждый раз” - честно говоря не понял.

Я о динамической типизации. С одной стороны ты прикладываешь усилия к обеспечению корректности типов, с другой стороны питон каждый раз их перепроверяет. Если бы можно было просто зафиксировать тип, было бы класно, реализовав, например, как генерики. Или, как вариант, типизация по Хиндли-Милнеру.
Собственно динамическая типизация - моя самая нелюбимая фича питона. И ущербная лямбда тоже.

Андрей Светлов
Другое дело - мы научились неплохо обходить перечисленные трудности, а достоинств у Питона все же на порядок больше (по крайней мере в моих глазах).

Собственно у меня то же самое. Просто всегда хоется большего :)

Цикл такой: ежедневные (иногда бывают перерывы) билды, которые идут тестировщикам. Ежемесячно - выпуск новой версии для клиентов. Довольно вольготно.

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

Гораздо дороже обходится “давайте сделаем сейчас быстро и как-нибудь, а потом все-все исправим”. XP подразумевает создание быстрой работающей реализации, но при этом все равно требуется постоянно следить за архитектурой и писать тесты. Не делаешь этого - копаешь себе яму. Особенно если разработчиков много.