>>> то есть скажем веб приложения на перле я надеюсь никто не пишет?

В 90-ые все писали.

Некоторые до сих пор пишут.

К сожалению ещё пишут. Перлисты ушли и супорт не знает что с этим кодом делать. Глобальные определения, комментариев нет, ...

> Четыре страницы каментов уже настрочили, а ни одного довода, за чем вообще переносить программы с перла на питон так и не прозвучало.

Таки зачем?

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

Perl и Python - это частный случай. Когда-то многие переходили с ASP на ASP.NET. Видел полный переход проекта в течении 6 месяцев от C++ к Python, когда в задаче не требовалась скорость, а надёжность и простота разработки.

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

То есть питонистов много и они дешёвые? И, в случае чего, одного легко заменить другим без потерь?

Ну я JavaScript не учил, когда пришлось писать скрипты открыл руководство по языку, припомнил опыт изучения C++, и быстро и без проблемм написал всё что надо. Особенно мне понравилась оригинальная реализация ООП в этом чудесном языке.

Если поддержка программы определяется найденым программистом, то причин для перехода больше не надо. Нашли прогера на баше - переисали на баш. Пришел дельфист - накарябал на дельфи и т.д. ЗАчем для этого писать статьи?

к Python

надёжность

что-нибудь одно.

к Python

надёжность

что-нибудь одно.

Питон весьма надёжен, если не пользоваться первыми попавшимися левыми модулями.

> Питон весьма надёжен, если не пользоваться первыми попавшимися левыми модулями.

Ерунда какая
Скриптовые языки были придуманы для упрощения сборки и изменения программ, а не траха с их обратной совместимостью и пожизненной разбираловкой приколов от Гвидо.
Что , sympy это левый модуль ?
http://code.google.com/p/sympy/issues/detail?id=2148
Бггг, да пистон понятия не имеет про обратную совместимость.
У этого языка есть одна проблема - его автор.

>Питон весьма надёжен, если не пользоваться первыми попавшимися левыми модулями.

Полная ерунда. Пестон провоцирует написание ненадежного кода.

Ерунда какая

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

Ерунда --- это то, что вы это и сказали. В Питоне есть совместимость в рамках последних нескольких минорных версий. Вещи, предназначенные для выбрасывания, помечаются заранее и удаляются через пару выпусков. Да, в 3-тей ветке вроде бы всё совместимо в обратную сторону полностью пока.

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

> В Питоне есть совместимость в рамках последних нескольких минорных версий.

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

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

Верно, если каждая минорная версия пистона пишется с нуля))

Питон весьма надёжен, если не пользоваться первыми попавшимися левыми модулями.

Полная ерунда. Пестон провоцирует написание ненадежного кода.

Если вы пишите неграмотно, ни Ява, ни Скала вас не спасут, а уж тем более С++. Питон позволяет легко писать надёжный и достаточно производительный код. Если вы не умеете им пользоваться, это ваши проблемы.

Я не понимаю тут тррллят действительно знатоки Python-а, которым он не нравится, или фанатики чего-то другого, Python никогда не использующие? Чего вы ноете? Какие претензии к совместимости между минорными версиями? Большинство кода написанного для 1.6 продолжает работать вплоть до 2.7.x, которые все еще поддерживается. Переход от 2.7 на 3 больших заморочек не несет, так как на уровне API совместимоть довольна высока, а скрипты переносятся транслятором и руками за очень короткое время. Если большая часть кода покрыта юнит тестами проблемы в этом вообще нет. Нет серьёзных изменений ни в языке ни в библиотеках. Сам интерпретатор питона очень стабилен. Какие претензии к стабильности?

Увы, это все мантры слепого

http://stackoverflow.com/questions/1373255/making-python-2-6-exception-backwa...

и замечательный совет:
-------------------
The as syntax is specifically NOT backwards compatible because the , syntax is ambiguous and must go away in Python 3.

Ты пытался разобраться с проблемой или выдрал фразу из контекста не поняв проблемы? Старый код работает и в 2.5 и в 2.6 и в 2.7.

try:
    pr.update()
except ConfigurationException, e:
    returnString=e.line+' '+e.errormsg

> Ты пытался разобраться с проблемой или выдрал фразу из контекста не поняв проблемы?

Зачем ? Это был пример обратной совместимости. Могу еще привести.
Без рук старые программы могут не работать на новых версиях пистона , этого вполне достаточно обнуления всей вашей патетики.
А держать спецом человечка для ковыряния пистоне и быть «слегка в курсе» это уже лишнее.

elipse

Это был пример обратной совместимости. Могу еще привести. Без рук старые программы могут не работать на новых версиях пистона , этого вполне достаточно обнуления всей вашей патетики. А держать спецом человечка для ковыряния пистоне и быть «слегка в курсе» это уже лишнее.

Ты доказывал одно, а пытаешься протолкнуть другое. То что код написанный чисто для 2.7 не будет работать под 2.5 это нормально, так как развиваются не только библиотеки, но и язык (для какого языка кроме lisp это не так?). Написанное под 2.5 в 2.7 работает и этого достаточно.

> То что код написанный чисто для 2.7 не будет работать под 2.5 это нормально, так как развиваются не только библиотеки, но и язык

Вы вроде как сами с собой разговариваете ...))
И да, я не щитаю за развитие вытругивание новых версий либ в погоне за
мутациями базового ЯП.

Скажи честно, пил?

Perl5 несовместим с Perl6 в любую сторону. C# постоянно теряет совместимость от версии к версии (одни игры с generics 2-3чего стоят). Если говорить про обратную совместимость, то даже Java6 несовместима с Java4 на уровне синтаксиса.

> То есть питонистов много и они дешёвые? И, в случае чего, одного легко заменить другим без потерь?

Читаем то что было написано в том же сообщении:

Perl и Python - это частный случай.

Каждая фирма решает для себя что ей важнее.

> ЗАчем для этого писать статьи?

Видимо для тех кто сейчас переходит с Perl на Python, а не для всех критиков.

к Python

надёжность

что-нибудь одно.

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

> sympy это левый модуль ?

Разве он уже стандартный? Пишите им тикеты.

Бггг, да пистон понятия не имеет про обратную совместимость.

Мы без проблем перешли с 2.4 на 2.5, недавно на 2.6, успешно тестируется в 2.7, причём с набором внешних модулей.

>Видимо для тех кто сейчас переходит с Perl на Python, а не для всех критиков.

Я читал, один мерикос в северную корею сбежал. Наверное, для него.

Если кто-то выполнил фунциональную ошибку, то отправляется traceback, но система работает уверенно далее.

Ага. Программа вываливается.

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

Замечательная работа.

взгляд со стороны

Был perl!, люди приняли его как данность и эту данность начали развивать, не задаваясь вопросом, «будет он хорош или нет через ХYZ лет», «задай себе вопрос, будеш ли ты хорошо через 20 лет», и что сравнивать...., появление нового обусловлено не пониманием существущего, либо же благими намериниями ..., ;) : «я понял перл, но друзья нет, напишу для них чтото попроще», в итоге «Спираль» (повторение, с мыслю что это ново), движение есть прогресса нет ;).

pypy неработоспособен

http://speed.pypy.org/

Как-то так.

import select

poller = select.epoll(sizehint)

это некроссплатформенно

> В питоне по крайней мере синтаксис ЕСТЬ, в отличие от перловской каши.

Более того, в Питоне есть не один синтаксис! :)

> Ну я JavaScript не учил, когда пришлось писать скрипты открыл руководство по языку, припомнил опыт изучения C++, и...

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

Не угадали, потом я всё-же осознал разницу в самом подходе к написанию программ на JavaScript. Главное достоинство C-like языков - это лёгкость изучения синтаксиса ввиду их похожести в синтаксическом плане. Синтаксис Scheme - это идеал ввиду его простоты и логичности. Но из-за преобладания C-like языков и наследия Basic и школы Вирта(pascal,oberon,delphi, etc.) синтаксис Scheme заранее обречён на низкую популярность. Так вредные привычки незаметно портят нас. Что делать... Я кстати не профессиональный программист, мне писать быдлокод можно:) Хоть на JS, хоть на Python. Для меня это хоби, я на этом не зарабатываю.

epoll is a scalable I/O event notification mechanism for Linux

Некроссчто, простите? Где вы видели нелинуксовый epoll?

вот именно что нигде

то есть ты предлагаешь делать вот такие извраты в скриптовом языке?

import select

if sys.platform == 'linux':
  poller = select.epoll(sizehint)
else if sys.platform == 'bsd':
  poller = select.kqueue(sizehint)
else if sys.platform == 'wtf'
  poller = select.wtf(sizehint)
....

А нормальная обертка в питоне имеется?

[code] if sys.platform == 'linux': poller = select.epoll(sizehint) else if sys.platform == 'bsd': poller = select.kqueue(sizehint) else if sys.platform == 'wtf' poller = select.wtf(sizehint) [/code]

вот-вот, знаменитый «спагетти код», так любимый сишниками, что они «портируют» его на все, куда у них руки дотянуться. если тебе нужна «портабельность», зачем сам лезешь на низкий уровень? используй готовые библиотеки, те же twisted или gevent.

Нужно допилить третий питон :)

это можно, если задача параллелится хорошо и межпотоковое общение мало или отсутствует. Можно, правда, заюзать activemq/rabbitmq ...

Или подождать, пока все либы портируют на третий питон, в котором, вроде как, проблему частично решили

ловить ошибки всё-таки надо :)

> Можно, правда, заюзать activemq/rabbitmq ...

Да что угодно: UNIX sockets, memcached, TCP, UDP, database, ... Выбор огромен. От задачи зависит.

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

Любой «скриптик» полететь может. Может и ритмбокс помог. Питон может намного больше чем «скриптики».

Я про системы на Питоне говорю. И они выдают traceback конкретного файла, но сама система работает дальше годами, обрабатывая множество запросов одновременно на многопроцессорной системе.

Как бы тебе сказать...
У epoll и kqueue принципиально разный API.
Их, ба, нельзя вот так мешать. Под эти дела нужно писать две разных реализации.
А для кроссплатформенности poll() есть.

У epoll и kqueue принципиально разный API. Их, ба, нельзя вот так мешать

хорошо, что об этом не знали разработчики libev, libevent, boost::asio и других библиотек и смогли привести «принципиально разный API» к общему знаменателю.

там сплошная лажа

про регулярники которые в питон лучше я вообще упалпацтол, ни в каком языке нет регулярников по функционалу хотя бы на 30% таких же как в perl

а дальше по тексту сплошной тупняк

например

Например проверить вхождение элемента в список в Python проще:

и что может быть проще

if ($var ~~ @array) ?

Перегрузка операторов в Perl возможна, но является очень ограниченной и искусственной надстройкой

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

Python — изначально объектно-ориентированный язык, в Perl классы — достаточно искусственное образование.

perldoc Moose

В Python имеется полноценный механизм обработки исключений, встроенный в язык.

равно как и в перле. выбрасывая исключение никто не мешает выбрасывать объект исключения

где-то это логично (как например в Mojo), а где-то не нужно

Python-way более громоздок, за то он позволяет не только корректно обработать ошибку, но и вернуть любую информацию о ней

этот самый питонвай доступен и в перл

eval {
  бла
};
if ($@) {
  бле
}

для любителей конструкций try-catch-throw их есть у нас тоже

Perl все переменные глобальны, если не указано иное.

какой-то бред

Python гораздо более строг, чем Perl:

питон более строг чем перл у которого раздельные строковые и числовые операторы? не смешите мои тапки

fh = open('file', 'r')
for line in fh:
  print line,
fh.close()

не понял чем хуже

open my $fh, $file;
print $_ while <$fh>;

можно весь файл прогнать через map/grep/итп:

@lines = map "abc $_", grep /^def/, <$fh>;

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

Эмм на самом деле оно просто с ошибкой вылетит. Учите матчасть.

вылетит-то оно в рантайме а не на стадии компиляции

>> Эмм на самом деле оно просто с ошибкой вылетит. Учите матчасть.

вылетит-то оно в рантайме а не на стадии компиляции

Именно на стадии компиляции.

Perl5 несовместим с Perl6 в любую сторону

в обратную совместим путем использования стандартного модуля который написан Ларри Уоллом

Именно на стадии компиляции.

если судьба даст некомпилируемый отступ

  if бла:
     if blа:
  - вот тут и таб и четыре пробела будут компилироваться

если взять более глубокую вложенность то ситуаций компилируемых, но неправильных больше

Именно на стадии компиляции.

libastral уже встроили в компилятор python?

> вот тут и таб и четыре пробела будут компилироваться

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

Сталкивался с такими тонкостями только на первой стадии работы с Питоном. Со временем приучаешься к полному порядку в коде и уже много лет всё чётко.

>> Именно на стадии компиляции.

libastral уже встроили в компилятор python?

Пример или GTFO

Сталкивался с такими тонкостями только на первой стадии работы с Питоном. Со временем приучаешься к полному порядку в коде и уже много лет всё чётко.

эта проблема вообще не стоит когда над кодом работает один человек/команда.

когда нужно изготовить патч для чужой поделки итп вот тогда начинаются траблы

Пример или GTFO

пример я выше привел в тегах [ code ]