Гвидо ван Россум рассказывает об истории Python

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

Если вежливо попросишь, расскажу тебе на пальцах, что такое декораторы ;)

Вендузятнег детектед.

bzr и mercurial - популярнейшие DVCS. На subversion смотреть не хочется, после того, как начинаешь пользоваться ими.

trac вообще не VCS - это BTS + wiki. Тоже очень активно развивается и весьма популярен.

scons - система автоматизации сборки.

taskcoach - хз что это, лень в гугл лезть, сам поищи :)

sk1 - знаменитый векторный редактор отечественной разработки.

django, turbogears, web.py - веб фреймворки разной степени интеграции. Первый из них уделывает RoR и все фреймворки для PHP одной левой.

> Это его сильная сторона, но силой тоже нужно уметь правильно пользоваться

Remember, a Jedi's strength flows from the Force.

> А теперь попрошу такие задачи, где заведомо выиграет жаба.

Задача одна - с любой операционки прицепиться через tcp/ip к любой СУБД (во всех комбинациях).

Список поддерживаемых СУБД: http://wiki.python.org/moin/DatabaseInterfaces

Насчет операционки - интерпретатор отлично протестирован и работает на самых популярных, а собрать его можно вообще под любую платформу, для которой есть компилятор ANSI C.

Ну что, слив засчитан.

> Вендузятнег детектед.

> bzr и mercurial - популярнейшие DVCS. На subversion смотреть не хочется, после того, как начинаешь пользоваться ими.

ниасилил ни то, ни другое. C subversion полное взаимопонимание.

> trac вообще не VCS - это BTS + wiki. Тоже очень активно развивается и весьма популярен.

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

> scons - система автоматизации сборки.

Мне хватает make и ant.

> taskcoach - хз что это, лень в гугл лезть, сам поищи :)

я посмотрел - todo программиста - пишу на листочках бумаги. ;)

> sk1 - знаменитый векторный редактор отечественной разработки.

ничего про него не могу сказать - не использовал

> django, turbogears, web.py - веб фреймворки разной степени интеграции. Первый из них уделывает RoR и все фреймворки для PHP одной левой.

с веб программингом не связан

мдэ, люблю читать срачь... но давайте что-то новое кроме отступов.

>>Да при чем тут жаба... Она вообще, я думаю, не конкурирует с Python.

Питон папа?

>> bzr и mercurial - популярнейшие DVCS. На subversion смотреть не хочется, после того, как начинаешь пользоваться ими.

>ниасилил ни то, ни другое. C subversion полное взаимопонимание.

Все начинают с того, что проще, это нормально. Когда дело дойдет до параллельной разработки в разных ветках, поймешь, что CVCS (любая, не только сабвершн) - это ад. Работать с ветками ужасно не удобно. Лень подробно расписывать, это известный факт.

А зачем ты предпочитаешь использовать кроссплатформенные программы, если работаешь под вендой? :) И в каком страшном сне тебе привидилась идея установки серверного ПО на венду? :)

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

> Список поддерживаемых СУБД: http://wiki.python.org/moin/DatabaseInterfaces

Вы лично подключались ко всем СУБД и все работало на любых объемах? Чтение и запись? Русские букофки? Все поддерживаемые СУБД типы данных?

Oracle, MSSql 2k, 2k5, MySql, PostgresQl, Interbase, Firebird?

SQLAlchemy

Я имел дело только с mysql, postgres, oracle и sqlite. Могу твердо сказать, что все отлично.

А вообще анонимус правильно сказал, есть шикарные ORM, которые позволяют абстрагироваться от СУБД и работать с любой. При необходимости миграции (например, со склайт на этапе разработки на посгрес в продакшне) меняется одна строчка в конфиге - и усё. Just works.

> А зачем ты предпочитаешь использовать кроссплатформенные программы, если работаешь под вендой? :) И в каком страшном сне тебе привидилась идея установки серверного ПО на венду? :)

Я работаю и под виндой, и под linux. Идеологически современная винда очень похожа на linux. Почему бы серверный софт не поставить под нее? Очень часто операционку выбирает заказчик (или уже выбрал до тебя). То есть уже есть купленное и надо разработать/доработать именно под эту операционку, именно с этой СУБД. Вы же не будете отрицать, что имеется определенный процент серверов под виндой?

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

Расширять кругозор полезно, но, к сожалению, нельзя объять необъятное.

На питоне я программировал довольно много, но сейчас не использую вообще. В сутках всего 24 часа. ;-)

> Расширять кругозор полезно, но, к сожалению, нельзя объять необъятное.

Согласен. Однако важно понимать, что по-настоящему хороший программист расширяет кругозор и учится *всегда*. Это отличает его от быдлокодера.

> На питоне я программировал довольно много, но сейчас не использую вообще.

Это ты тот анонимус, который декораторы ниасилил? Расскажи, какие задачи решал на python? Почему перестал использовать? Какой язык/технологии используешь сейчас?

> есть шикарные ORM, которые позволяют абстрагироваться от СУБД и работать с любой

Дело, как мне кажется, даже не в ORM, а в jdbc.

Сейчас выпустить СУБД без jdbc равносильно самоубийству. Сразу потеря доли рынка. А раз есть jdbc - причем довольно хорошо стандартизированный - то сверху на него можно и фреймворк навернуть.

В java тоже все не гладко - серверные программы на java жрут много памяти. Но для написания клиентов - слить данные из одной базы в другую - подходит идеально.

> Это ты тот анонимус, который декораторы ниасилил? Расскажи, какие задачи решал на python? Почему перестал использовать? Какой язык/технологии используешь сейчас?

python использовал для внутренних задач. Анализ текстов программ, поисковые движки. Не использую, потому что нет рынка труда программистов на python (или он есть но очень маленький).

сейчас использую sql/java.

Работа с JDBC есть в Jython. Там кстати и GIL нет :)

> python использовал для внутренних задач. Анализ текстов программ, поисковые движки.

Как-то неубедительно. Простые скриптики, которые можно и на баше и егреп писать?

Насчет спроса на программистов python - ошибаешься. Я, скажем, когда менял работу в последний раз, выбирал из предложений с учетом близости к моей ветке метро ;)

Вообще действительно вывод можно сделать простой - о недостатках python громче всех кричат те, которые или вообще не разобрались (даже не пытались), или разобрались лишь поверхностно, возможно, понаслышке.

> Вообще действительно вывод можно сделать простой - о недостатках python громче всех кричат те, которые или вообще не разобрались (даже не пытались), или разобрались лишь поверхностно, возможно, понаслышке.

У каждого языка есть своя область применения. Для задач, которые я сейчас решаю, больше подходит java.

И кроме того у python:

мне не нравится отсутствие статической проверки. Ну вот такой я человек - мне больше нравятся статические языки.

мне не нравится низкая скорость языка. Несмотря на наличие большого количества библиотек написанных на C и завернутых в Python чего-то может не хватить. Реализация на чистом python будет медленна.

Не нравится невозможность из коробки создать windows service на python.

Не нравится низкая производительность регулярных выражений (если сравнивать с движками на NDFA http://www.brics.dk/automaton/)

Не нравится его однозадачность.

Не нравится отсутствие визуального отладчика.

Не нравится отсутствие возможности прицепиться отладчиком к работающему процессу.

Мне не нравится космо^Wастронавт, который несколько лет висит на странице www.python.org. Что для программирования на питоне надо выходить в открытый космос? ;)

А во всем остально язык не плохой и на нем тоже можно создавать работающие программы.

> мне не нравится отсутствие статической проверки. Ну вот такой я человек - мне больше нравятся статические языки.

so true

> Не нравится отсутствие визуального отладчика.

> Не нравится отсутствие возможности прицепиться отладчиком к работающему процессу.

PyDev + PyDev Extensions.

Остальное - вкусовщина и придирки. В любом случае, не претензии к _языку_ - скорее, к конкретной реализации.

> PyDev + PyDev Extensions.

Спасибо, я не знал про то что появился отладчик.

> Остальное - вкусовщина и придирки. В любом случае, не претензии к _языку_ - скорее, к конкретной реализации.

Несомненно, да. Это мое субъективное (неправильное) мнение.

Утилиты SELinux реализованы на C и (OMG!) питоне.
SELinux => NSA (OMG!)
Задумайтесь, товарищи!

капча greping какбе намекает, что большой брат grepping you.

>> PyDev + PyDev Extensions.

>Спасибо, я не знал про то что появился отладчик.

Отладчик был всегда - pdb. Он, между прочим, почти во всем подобен gnu gdb. Ну и к нему еще есть ipdb - мегаудобная штука, которой, кстати, не может быть в статических языках.

Насчет остальных придирок: большая часть - 4.2. Если уж берешься так строго судить, потрудился бы узнать получше то, о чем судишь.

>А теперь попрошу такие задачи, где заведомо выиграет жаба.

Веб приложения (вообще любые). Для питона это утверждение неверно. Он не масштабируется, и для больших нагрузок непригоден. использование библиотек на С ситуацию только усугубляет, поскольку нет кроссплатформенности и отладка сложных приложений превращается в кромешный ад.

>> А теперь попрошу такие задачи, где заведомо выиграет жаба.

>Веб приложения (вообще любые). Для питона это утверждение неверно. Он не масштабируется, и для больших нагрузок непригоден.

Вон оно как, а мужики из Google и Яндекса-то не знают. Масштабируется, не надо вводить неискушенных анонимусов в заблуждение. Вот пример для любознательных: http://www.polimetrix.com/pycon/slides/

Для Ъ краткий пересказ: грамотное использование кеширования, балансировщик нагрузки и трезвый подход к оптимизации позволяют масштабировать web-приложения на python сколько угодно.

балансировка нагрузки и кеширование никакого отношения к движку на пистоне не имеют. Вопрос стоит стоит как вырастет производительность при переходе с 2 процов с 4 гигами памяти, на 8 процов и 32 гига памяти.

Сможет ли пистоновский энжайн утилизировать такие ресурсы разумным образом?

Короткий ответ: да.

Основная идея: использование балансировщика нагрузки + запуск стольких процессов интерпретатора, сколько есть физических ядер, позволяет вообще исключить проблему утыкания в GIL. Можно сделать сложнее - с использованием модуля multiprocess, но тут надо больше думать, и не факт, что выйдет оптимальней.

А как это будет выглядеть на системах с 100 тыс. одновременных коннектов? Получим 100 тыс. процессов?

Если это просто keep-alive, их все будет держать реверс-прокси-балансировщик, ничего не зависит от python. А если это какбе comet, разумно запустить, скажем, 1к процессов (на двух дюжинах машин по сорок) с пулом в 100 воркеров в каждом. Хотя вообще не знаю, насколько цифра в 100к *одновременных* коннектов (не keep-alive) вообще соотносится с реальной жизнью.

вообще питон - интересный язык
с одной стороны , лаконичный
с другой - куча полезных функций

> django, turbogears, web.py - веб фреймворки разной степени интеграции. Первый из них уделывает RoR и все фреймворки для PHP одной левой.

А второй двумя левыми?

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

С ходу: 1. Limbo 2. Oberon 3. Perl

>Когда дело дойдет до параллельной разработки в разных ветках, поймешь, что CVCS (любая, не только сабвершн) - это ад.

Уж лучше git чем mercurial. Так что mercurial, бесполезное и глючное быдлоподелие

Oberon - компилируемый язык. Да и вообще, где они щас? Кроме любопытствующих никто их не использует, ну кроме перла разве что.

Вообще конечно да, можно не делать глобальной блокировки, использовать вместо нее множество условных. Но наврдяли это будет сильно полезно: были попытки реализовать atomic operations для python. Закончилось дело печально - накладные расходы на огромное количество критических секций превысили все достоинства реализации - она оказалась медленнее в разы.

http://en.wikipedia.org/wiki/Linearizability

> Уж лучше git чем mercurial. Так что mercurial, бесполезное и глючное быдлоподелие

Офигенное умозаключение, что-то у тебя с логикой не в порядке :)

Да, гит сейчас моден среди быдла от линакса, мы уже знаем.

>А как это будет выглядеть на системах с 100 тыс. одновременных коннектов? Получим 100 тыс. процессов?

сначала хаите, а потом показываете свою некомпетентность в вопросе=)

для системы в 100тыс. коннектов актуально использовать асинхронный механизм и несколько форков серверов за балансировщиков, с такой задачей Twisted вполне справится, хотя существуют другие решения, аля greenlet(низковесные нити, кстати крикунам что "GIL гавно", должно заткнуть рот), coroutine и другие механизмы. Простинький асинхронный скрипт вполне справляется с обработкой/генерацией 1-2к req/sec

Отчасти решение зависит от архитектуры приложения, а не скорости интерпретатора и выбора языка...

>отступы это ублюдочная вещь. >язык который не позволяет сделать в одну строку следующее: >for i in list: callfunc(i) >Должен сдохнуть и вернуться обратно в 80-е годы. >А руби еще сильно коряв и тормозен, чтоб его серьезно юзать.

Мальчик, сколько тебе лет? for i in a:print int(i)

> расскажу тебе на пальцах, что такое декораторы

А в свободжное время вы ходите на стадионы и рассказываете легкоатлетам про инвалидные коляски?

Представь, я считаю, что знаниями нужно делиться.

То, что ты ниасилил декораторы, сразу делает их для тебя инвалидной коляской? Ты умеешь управлять локомотивом? Нет? Значит поезда не нужны. Так?

> То, что ты ниасилил декораторы, сразу делает их для тебя инвалидной коляской?

Нет. Просто ЯП, в котором нужны декораторы, - несомненный инвалид. Так понятней?

Это ты, похоже, непонятлив.

Python'у не "нужны" декораторы. Они просто там есть, они просто офигенная удобная супермегафича. Но их можно и не использовать. Вообще. Точно так же можно путешествовать пешком, хотя это очень долго и утомительно, а можно на поезде.

Так понятней?

> Просто ЯП, в котором нужны декораторы, - несомненный инвалид.

Ты не тот анонимус, который не мог цикл в одну строку записать?

> Это ты, похоже, непонятлив.

Попрыгай ещё.

> Они просто там есть, они просто офигенная удобная супермегафича. Но их можно и не использовать. Вообще. Точно так же можно путешествовать пешком, хотя это очень долго и утомительно,

Разумеется на инвалидной коляске удобней кататься, чем на брюхе ползать. Но вот на ногах ходить всё равно удобней и быстрее.

Доступно?

> Ты не тот анонимус, который не мог цикл в одну строку записать?

Нет. Я циклы вообще не использую. Незачем.

Ты безнадежен. Дай угадаю, ты пишешь в машинных кодах, а все, что ассемблер и выше уровнем - это инвалидные коляски для тебя? Уползай обратно в каменный век. Уходи быстро и удобно на своих ногах, пока другие летят вверх и вперед с джет-паками за спиной ;)

>Ты безнадежен. Дай угадаю, ты пишешь в машинных кодах, а все, что ассемблер и выше уровнем - это инвалидные коляски для тебя? Уползай обратно в каменный век. Уходи быстро и удобно на своих ногах, пока другие летят вверх и вперед с джет-паками за спиной ;)

Я тоже циклы не использую)) и пишу на питоне)) лист копрехеншн и мап)) что я делаю не так?

и фильтр с редьюсом в кучу

1х это циклы, циклы по итераторам.

> Ты безнадежен. Дай угадаю, ты пишешь в машинных кодах,

А еще что-нибудь знаешь? Не стесняйся, угадывай.

> Уползай обратно в каменный век. Уходи быстро и удобно на своих ногах, пока другие летят вверх и вперед с джет-паками за спиной ;)

Неа. Здорового человека хоть и можно приучить ползать на костылях потому что "тут так принято", но рано или поздно он учится ходить.