Решил тут посмотреть на этот язык.
Уж больно много про него сказано/написано. Да и голову размять немного полезно.

Язык конечно симпатичный — чем-то он мне smalltalk напомнил.
Но вот беда — настолько уже привык к статическому контролю типов и более строгим правилам, что вкрались у меня сомнения — а можно ли сделать на этом языке что-либо надежное за приемлемое время.

Расскажите, кто работал с Python — какого оно? Какие объемы проектов делали, что за проблемы были.

Да и вообще интересно ваше мнение о применимости языка. Мне пока видится что это всякие скрипты для команды разработки — deploy etc, а также клей для тонкой настройки приложений.

Также при моей невнимательности можно только по TDD работать — иначе очень быстро все так запутывается, что тушите свет. Может быть не привык еще.

Кстати среды для unit тестирования тоже не нашел нормальной. Какая наиболее удобна и популярна сейчас?
Да и IDE после VS2005 мягко говоря неудобный (опять же смотрел несколько бесплатных продуктов и у всех что-нибудь да отваливается).

Вобщем все это непривычно, но хочется разобраться, что за змей такой.

Расскажите, а?

Здравствуйте, DaBro, Вы писали:

DB>Решил тут посмотреть на этот язык.
DB>Уж больно много про него сказано/написано. Да и голову размять немного полезно.

DB>Язык конечно симпатичный — чем-то он мне smalltalk напомнил.
DB>Но вот беда — настолько уже привык к статическому контролю типов и более строгим правилам, что вкрались у меня сомнения — а можно ли сделать на этом языке что-либо надежное за приемлемое время.

Можно, реально похоже надежность мало зависит от типизации.

DB>Расскажите, кто работал с Python — какого оно? Какие объемы проектов делали, что за проблемы были.

Порядка 20000 строк на питоне + 10000 библиотек на с++.
Проблемы были только со стороними (PIL) библиотеками. Пришлось пару баг репортов им послать.

DB>Да и вообще интересно ваше мнение о применимости языка. Мне пока видится что это всякие скрипты для команды разработки — deploy etc, а также клей для тонкой настройки приложений.

Также полное написание небольших игр на питоне (графика и другой низкий уровень библиотека на C++).

DB>Также при моей невнимательности можно только по TDD работать — иначе очень быстро все так запутывается, что тушите свет. Может быть не привык еще.

Поначалу да, делаешь глупые ошибки, с некторым опытом их практически уже не допускаешь. Я TDD практически не использую, но делаю очень много интерактивных тестов + обязательные функциональные тесты. Какого-то увеличения ошибок по сравнению со статикой не замечал.

DB>Кстати среды для unit тестирования тоже не нашел нормальной. Какая наиболее удобна и популярна сейчас?

Средами не пользовался но чем не подходит стандартный модуль unittest?

DB>Да и IDE после VS2005 мягко говоря неудобный (опять же смотрел несколько бесплатных продуктов и у всех что-нибудь да отваливается).

Хорошее IDE это WingIDE правда оно платное но не дорогое.

Здравствуйте, DaBro, Вы писали:

DB>Решил тут посмотреть на этот язык.

DB>Да и вообще интересно ваше мнение о применимости языка. Мне пока видится что это всякие скрипты для команды разработки — deploy etc, а также клей для тонкой настройки приложений.

Знаю один большой проект на питоне. Civilization IV называется..

Писал на Python-е систему репликации.
Несколько скриптов для крона и svn (каждый <20 модулей)

На PyQt — помошьник для перевода специализированной базы.
Собственно в начале использовал PyQt для прототипирования юзабилити, собираясь в дальнейшем перевесть на С++ чтобы не тормозило.
Переводить не потребывалось!
Общее увеличение производительности переводчика более чем на порядок.

Здравствуйте, DaBro, Вы писали:

DB>Но вот беда — настолько уже привык к статическому контролю типов и более строгим правилам, что вкрались у меня сомнения — а можно ли сделать на этом языке что-либо надежное за приемлемое время.
DB>Расскажите, кто работал с Python — какого оно? Какие объемы проектов делали, что за проблемы были.

Рассказываю: на плюсатах пишу всё меньше и меньше, по тому как на питоне сухо и мяки НО, заметь я вообще человек со странностями, мне SmallTalk нравится

Если серьёзно, не только можно на нём писать, но и нужно. Язык не только удобный синтаксически но и очень мощный в плане парадигм программирования. А статический контроль типов — ИМХО, от этого только головная боль и синтаксический онанизм в духе С++, но в незащищённой среде на голом железе иного пути нет.

Ещё очень важно что язык легко расширяем и поддаётся тонкой настройке под конкретную задачу.

Одно удручает, не смотря на то что про него много сказанно, python слабо популизируется и рекламируется, как унивирсальное средство разработки — а значит и развивается существенно медленнее чем мог бы.

Вот пытаюсь достучаться до модерторов с вопросом: как бы так сделать чтобы на RSDN был раздел по питону — молчат. Наверное у себя на сайте делать придётся.

Здравствуйте, FR, Вы писали:

FR>Хорошее IDE это WingIDE правда оно платное но не дорогое.
Я komodo предпочитаю, но правда и пишу я не только на питоне

Здравствуйте, Alexey Chen, Вы писали:

AC>Вот пытаюсь достучаться до модерторов с вопросом: как бы так сделать чтобы на RSDN был раздел по питону — молчат.

Не знаю как по питону, а вот по динамическим языкам форум давно уже назрел.

Здравствуйте, ie, Вы писали:

ie>Не знаю как по питону, а вот по динамическим языкам форум давно уже назрел.

Боюсь в нем будет филиал Философии программирования.
Хотя одна радость есть. Это будет место где можно будет пообщаться с FR и eao197 без меня.

Здравствуйте, ie, Вы писали:

AC>>Вот пытаюсь достучаться до модерторов с вопросом: как бы так сделать чтобы на RSDN был раздел по питону — молчат.
ie>Не знаю как по питону, а вот по динамическим языкам форум давно уже назрел.

Дык, всёравно молчат

А в форуме по динмическим, можно было бы ещё и всякие интересности обсуждать типа self'a, динамической компиляции, другого нежели в С++ метапрограммирования, аспектов... Причём не в теориии, но в практической плоскости. Однака, сдаётся мне мало нас таких, а чтобы было много, нужно чтобы было средство популизации, а для этого нужно чтобы было много ... в общем типа замкнутого круга получается

ЗЫ.
про ruby специально не говорю, у него свои апологеты есть.

Здравствуйте, Alexey Chen, Вы писали:

AC>А в форуме по динмическим, можно было бы ещё и всякие интересности обсуждать типа self'a,

Так и вижу self vs. Ruby или бои без правил с eao197!

AC>динамической компиляции, другого нежели в С++ метапрограммирования, аспектов...

Для этого как раз текущий форум и редназначен. Все это как бы к скриптам прямого отношения не имеет.

AC> Причём не в теориии, но в практической плоскости.

Ага. А тут значич в теории все обсуждается?

AC> Однака, сдаётся мне мало нас таких, а чтобы было много, нужно чтобы было средство популизации, а для этого нужно чтобы было много ... в общем типа замкнутого круга получается

Пишите статьи. Мы с удовольствием опубликуем.

На форум скрипты явно не тянут. Все что касается веба можно обсуждать в соотвествующем оруме. Метапрограммирование и аспектное программирование тут. В прочем, открывайте глосование и если много народа прогалосует за форум, то можно и подумать. Ничего невозможного нет.

AC>про ruby специально не говорю, у него свои апологеты есть.

Да и мы его хорошо знаем и любим.

Здравствуйте, VladD2, Вы писали:

AC>>А в форуме по динмическим, можно было бы ещё и всякие интересности обсуждать типа self'a,
AC>>динамической компиляции, другого нежели в С++ метапрограммирования, аспектов...
VD>Для этого как раз текущий форум и редназначен. Все это как бы к скриптам прямого отношения не имеет.

Если обсуждать в форуме 'декларативное программирование' аспекты в питоне ещё можно, то реализации персистентности или UI — нет, целевая аудитория питона сюда не пойдёт ИМХО, форум не тот.

AC>> Причём не в теориии, но в практической плоскости.
VD>Ага. А тут значич в теории все обсуждается?

Да. Как взгляд со стороны, я же в основном читатель

AC>> Однака, сдаётся мне мало нас таких, а чтобы было много, нужно чтобы было средство популизации, а для этого нужно чтобы было много ... в общем типа замкнутого круга получается
VD>Пишите статьи. Мы с удовольствием опубликуем.
VD>На форум скрипты явно не тянут. Все что касается веба можно обсуждать в соотвествующем оруме. Метапрограммирование и аспектное программирование тут. В прочем, открывайте глосование и если много народа прогалосует за форум, то можно и подумать. Ничего невозможного нет.

Хм, это мнение редакции или отдельно взятого модератора? Как-то на письма мне никто не ответил даже простого 'нет'.
ИМХО, Java тот же скрипт, только её пиарили много и долго, как результат развивалась она быстрее, а уж как пиарили C#... Но твою точку зрения я понял: создайте коммунити и приводите к нам — точка зрения понятна и оправданна.

Здравствуйте, Alexey Chen, Вы писали:

AC>Если обсуждать в форуме 'декларативное программирование' аспекты в питоне ещё можно, то реализации персистентности или UI — нет, целевая аудитория питона сюда не пойдёт ИМХО, форум не тот.

Для UI есть соотвествующие форумы.

В общем, не надо выдумывать. Если речь идет о Питоне, то не надо приделывать с боку темы вроде метапрограммирования.

AC>Да. Как взгляд со стороны, я же в основном читатель

Для меня как глядящего со стороны вообще смысла в Питне нет. Это же не повод хоронить язык? Многие из тут обитающих применяют обсуждаемое на практике.

AC>Хм, это мнение редакции или отдельно взятого модератора?

Смотря по какому поводу.

AC>Как-то на письма мне никто не ответил даже простого 'нет'.

Я и писем не видел. Собственно вопрос с форумами (если о нем речь) решается очень просто. Если появляется значительный трафик по некторому вопросу (причем обособленный, а не в контексте других проблем), то обдумывается создание форума. А просто по просбам трудящихся форумы создаются очень редко.

AC>ИМХО, Java тот же скрипт,

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

AC> только её пиарили много и долго, как результат развивалась она быстрее, а уж как пиарили C#... Но твою точку зрения я понял: создайте коммунити и приводите к нам — точка зрения понятна и оправданна.

Создавать в общем-то ничего не надо. Но создавать форум в котором будет 5 вопросов в месяц мы точно не будет. Форумы требуют модерирования и т.п. И мертвяки усложняют жизнь.

В общем, самый простой способ подвигнуть нас к созданию новго форума — это создать голосование. Ну, или просто задавать много вопросов именно по скриптовым языкам.

IMHO
Хорошо использовать для слоев баз данных и веб сервисов, то есть обвязка быстрых движков на плюсах. С базами если использовать что-то типа SqlAlchemy, то Hibernate и ActiveRecord отдыхают. И для веба качественного инструментария завались, при чем можно выбрать то что нужно, а не брать все скопом, как с RoR. Об WingIDE тут уже написано, подтверждаю — вещь толковая.

Если действительно нужна надёжность в большой системе, то нужно писать юнит тесты. Так как разработка на П. идёт быстрее, то времени на них больше.

Проблема для меня одна — скорость. Если нужно быстро дробить числа и нет готовых компонент вроде NumPy, то придеться ковырять плюсы, а интеграция добавит сложность и время.

novitk wrote:
> Хорошо использовать для слоев баз данных и веб сервисов, то есть обвязка
> быстрых движков на плюсах. С базами если использовать что-то типа
> SqlAlchemy, то Hibernate и ActiveRecord отдыхают.
При всем моем уважении к Python, сравнивать SqlAlchemy _значительно_
проигрывает Hibernate по многим параметрам. В Hibernate намноно больше
типов мэппинга, лучше проработаны механизмы кэширования и т.п.

А вот лучше чем ActiveRecord — это точно.

Здравствуйте, Cyberax, Вы писали:
C>А вот лучше чем ActiveRecord — это точно.

Кстати сейчас сделал в текущем проекте "двухслойный" сервер приложений:

1. Нижний слой — web-сервисные модули ( на java + hibernate ), реализующие
хранение бизнес-обектов и набор операций над ними.

2. Верхний слой — общая логика и пользовательский интерфейс ( на RubyOnRails ).
Эти "модули отображения" не имеют своих "хранимых" объектов и своей
базы данных, а соответсвенно их можно запускать сколько угодно копий
паралельно (для масштабирования решения).

C>При всем моем уважении к Python, сравнивать SqlAlchemy _значительно_
C>проигрывает Hibernate по многим параметрам. В Hibernate намноно больше
C>типов мэппинга, лучше проработаны механизмы кэширования и т.п.

Поясню свой флэйм на Hibernate. Изначально скажу, что я в нем не эксперт, но имел счастье посмотреть как используется в похожем на мой по тематике проекте, где моя роль ограничивалась советами/критикой по дизайну. В этой области базы данных это, ну отсилы 15% задачи, так что для меня главные критерии хорошего инструмента — быстрая разработка и что бы граблей было поменьше.

Фишек в Hibernate действительно куча — согласен. Ну тут как с плюсами. При виде всех этих прибамбасов народ начинает теряться, а как собственно делать? Есть конечно рекомендации всяких умных дядек, но это же все теория. Оно конечно весело, но для дела не очень полезно, так как база данных аспект, повторюсь, мелкий. Все эти хитрые мэппинги, HQL-и, тонны ХМЛ-я, у меня ковырять ни времени ни желания нет. А "тупым индусам" это отдать страшно, по тому как это не кнопки на формы клепать.

Грубо говоря я за заточенный инструмент, а не за букет в одном флаконе. По этим причинам я и предпочитаю движки которые дают именно реляционную алгебру (LINQ, SqlAlchemy), а ORM это настройка, как и кэширование кстати. Не нравиться ихний ORM, могу заделать свой или вообще обойтись.

Я впрочем не считаю Hibernate отстоем, и если нужно "сидеть" в Java-e пользовал бы именно его. Просто сейчас после появления SqlAlchemy, с сострадаем смотру на людей которые делают обвязку для базы на оном.

Аноним wrote:
> Фишек в Hibernate действительно куча — согласен. Ну тут как с плюсами.
> При виде всех этих прибамбасов народ начинает теряться, а как собственно
> делать? Есть конечно рекомендации всяких умных дядек, но это же все
> теория. Оно конечно весело, но для дела не очень полезно, так как база
> данных аспект, повторюсь, мелкий. Все эти хитрые мэппинги, HQL-и, тонны
> ХМЛ-я, у меня ковырять ни времени ни желания нет. А "тупым индусам" это
> отдать страшно, по тому как это не кнопки на формы клепать.
Hibernate элементарно можно начать использовать при минимальных знаниях
того, что такое "реляционная модель". Мэпинги там абсолютно несложные,
еще в первой Hibernate я их освоил за час.

> Грубо говоря я за заточенный инструмент, а не за букет в одном флаконе.
> По этим причинам я и предпочитаю движки которые дают именно реляционную
> алгебру (LINQ, SqlAlchemy), а ORM это настройка, как и кэширование
> кстати. Не нравиться ихний ORM, могу заделать свой или вообще обойтись.
Вообще-то, к реляционной алгебре SqlAlchemy имеет отношение точно такое
же, как и Hinernate.

> Я впрочем не считаю Hibernate отстоем, и если нужно "сидеть" в Java-e
> пользовал бы именно его. Просто сейчас после появления SqlAlchemy, с
> сострадаем смотру на людей которые делают обвязку для базы на оном.
Ну так что в SqlAlchemy такого? Ну не вижу ничего абсолютно. Мэпинги
почти такие же. Язык запросов только немного поприятнее из-за
динамических фич Питона.

Alex EXO wrote:
> Кстати сейчас сделал в текущем проекте "двухслойный" сервер приложений:
> 1. Нижний слой — web-сервисные модули ( на java + hibernate ), реализующие
> хранение бизнес-обектов и набор операций над ними.
> 2. Верхний слой — общая логика и пользовательский интерфейс ( на
> RubyOnRails ).
> Эти "модули отображения" не имеют своих "хранимых" объектов и своей
> базы данных, а соответсвенно их можно запускать сколько угодно копий
> паралельно (для масштабирования решения).
Как вариант неплохо. А как overhead от межпроцессного общения? Не заметно?

Здравствуйте, Cyberax, Вы писали:

C>Hibernate элементарно можно начать использовать при минимальных знаниях
C>того, что такое "реляционная модель". Мэпинги там абсолютно несложные,
C>ещё в первой Hibernate я их освоил за час.

Ну да, и "hello, world" на плюсах, то же просто и понятно. Если модель простая, то ORM вообще не нужен, а нужен удобный портативный DB-API, о котором в SqlAlchemy пол книги, а в Hibernate мне с ходу не понятно, как что-то с базой сделать без создания всяких PoJo, XML-a и прочей хрени, не погружаясь, так сказать в JDBC. А со сложной моделью тут надо знать досконально и очень часто простота в цене. Hibernate весьма не прост:
http://shinetech.com/display/www/The+Good+News+And+The+Bad+News

C>Ну так что в SqlAlchemy такого? Ну не вижу ничего абсолютно. Мэпинги
C>почти такие же. Язык запросов только немного поприятнее из-за
C>динамических фич Питона.

1) Нет HQL
2) Maштабируется вниз, когда ORM не нужен.
3) Простота и как следствия грабли видны быстрее

Встречный вопрос, что в Hibernate такого?
Kэширование? Как уже сказал для меня оно ортогонально, то есть JCA это хорошо, но встраивать в мэппер не обязательно и даже вредно.

Inheritance mapping strategies? От лукавого все это...Проблем больше, чем удобства.

Что там еще?

novitk wrote:
> Ну да, и "hello, world" на плюсах, то же просто и понятно. Если модель
> простая, то ORM вообще не нужен, а нужен удобный портативный DB-API, о
> котором в SqlAlchemy пол книги, а в Hibernate мне с ходу не понятно, как
> что-то с базой сделать без создания всяких PoJo, XML-a и прочей хрени,
> не погружаясь, так сказать в JDBC.
А зачем ВООБЩЕ нужен "портативный DB API"? Вот этого я не очень понимаю.

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

> А со сложной моделью тут надо знать
> досконально и очень часто простота в цене. Hibernate весьма не прост:
> http://shinetech.com/display/www/The+Good+News+And+The+Bad+News
Ну и? Для SqlAlchemy, да даже и для чистого SQL, большая часть того что
там написана тоже относится.

> C>Ну так что в SqlAlchemy такого? Ну не вижу ничего абсолютно. Мэпинги
> C>почти такие же. Язык запросов только немного поприятнее из-за
> C>динамических фич Питона.
> 1) Нет HQL
Это плюс?

> 2) Maштабируется вниз, когда ORM не нужен.
Тогда зачем брать ORM? Берем iBATIS и не городим огород.

> 3) Простота и как следствия грабли видны быстрее
Где простота? Не вижу ее.

> Встречный вопрос, что в Hibernate такого?
Очень мощный mapping — пожалуй лучший из тех что я видел, поддержка
настоящего ORM (включая identity mapping), продуманная схема работы с
транзакциями, поддержка JTA (но это уже Java-specific), хорошая
поддержка lazy-loading'а, удобный язык запросов, интеграция с серверами
приложений.

> Kэширование? Как уже сказал для меня оно ортогонально, то есть JCA это
> хорошо, но встраивать в мэппер не обязательно и даже вредно.
Нет, кэширование как раз должно быть на уровне mapping'а.