Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, andyag, Вы писали:
A>>С практической точки зрения нет смысла рассматривать Python как самостоятельный инструмент.
KP>Ты не прав. Инструмент очень удачный. Он простой в изучении, он относительно прост в поддержке и он базируется, наверное, на самых правильных принципах в разработке ПО, какие только можно придумать (PEP 20). А еще у них есть замечательные IPython с Notebook.
Zen of Python неявно существует в абсолютно любом ЯП. Главное чтобы автор кода верил, что придерживается этого дзена — тогда у него есть гармония. Но читатели кода часто несогласны, что написанный код имеет какое-то отношение к дзену и вульгарно называют код — говнокодом.
A>>1. Комьюнити уже 6 лет не может переехать с версии на 2 на версию 3 — это самый большой факап.
A>>2. Из-за п.1 часть старых зрелых библиотек не доступна на Python 3.
KP>Проблема есть, она, иногда, создает неудобства. Но я бы не сказал что это что-то критическое, сколь-нибудь сильно мешающее разработке на нем.
Это снова что-то сильно субъективное. Если оно не мешает вашим кейзам, это не значит, что оно не мешает вообще. Это как-то нездорово — чувствовать себя спокойно, когда знаешь, что завтра может понадобиться какая-то библиотека для XXX, которой может не быть для Python 3, в то время как остальная часть проекта уже написана именно на 3. Это просто ненормально.
A>>3. У Python нет адекватного менеджера зависимостей. Есть убогий pip, который выглядит как недоделанный костыль (если сравнивать с аналогами для других языков). Хрен с ним, что костыль, но далеко не все библиотеки через него доступны.
KP>Менеджер как менеджер. Не самый лучший, но однозначно выполняющий свою задачу. Пакетов в нем много, у меня не так что бы очень уж обширный Python опыт, но почти все находилось. Плюс еще можно поставить Конду и вообще жизнь станет прекрасной.
Просто чтобы я мог оценить ваше высказывание в полной мере — когда вы говорите "не самый лучший", какой "самый лучший" вы имеете в виду?
A>>Python можно рассматривать как тул для реализации логики отдельных частей приложения: весь хардкор написать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%, а потом скрутить этот хардкор в кучу через Python. Например есть реализация Python на Java — Jython. Но с таким же успехом там есть и JavaScript, и JRuby и ещё штук 10 менее попсовых языков.
KP>Нет-нет и еще раз нет. Python можно и нужно рассматривать как основной кандидат для написания не критичной ко скорости логики. Именно по тем причинам, что я привел в самом начале.
Не понял с чем вы спорите — я сказал почти то же самое. Более того, тут вы подтверждаете мое самое первое утверждение — "С практической точки зрения нет смысла рассматривать Python как самостоятельный инструмент".
A>>Python можно рассматривать как тул для всяких экспериментов — типа запрограммировать алгоритм, посмотреть как он работает, а потом переписать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%. У него есть какие-то там интересные математические библиотеки, поэтому для таких задач оно может иметь смысл.
KP>Зачем переписывать? Есть серьезное подозрение что проблема в не умении его готовить, а не самом языке.
И нафига мне алгоритм на Python, если остальной код написан, например, на C#? Проясню ситуацию: я делаю какой-то проект на C#, возникает необходимость запилить какой-то не очень тривиальный алгоритм. Я хочу сначала пощупать этот алгоритм, проверить на разных данных, порисовать какие-то графики — в этом случае я возьму Python. Но как только нащупаюсь, перепишу всё на C#.
A>>Python можно рассматривать как тул для скриптов, замену всяким *.bat и *.sh, т.к. стандартная библиотека у него вполне интересна — многое можно сделать в 2 строчки без запуска внешних процессов и разбора их вывода через grep и прочие ужасы. Но примерно с таким же успехом можно использовать и тот же Ruby, и Groovy, и даже NodeJS при должной мотивации.
KP>А почему для более сложных задач нельзя? На нем можно великолепно писать всяческие считалки (привет NumPy с Pandas) так и сервера (тут очень интересен Twisted). Единственное о чем бы я 10 раз подумал, перед тем как писать на Python – GUI приложения. У меня есть подозрения (не пробовал, только гадать могу), что в этой области выйдет не очень.
Ни разу не спорю, что можно. Вопрос в том, какая должна быть мотивация, чтобы выбрать Python, а не что-то другое. Если про NumPy мне возразить нечего (и не хочу — см. предыдущий пункт про "алгоритм"), то тот же Twisted — это совершенно точно не киллер-фича Python. Сейчас практически на любой платформе есть своё супер-производительное асинхронное решение для построения сетевого фасада. Но у многих из этих платформ ещё и нет недостатков, описанных выше, поэтому зачем Python?
A>>ИМХО, Python это недо-Ruby, а Ruby в свою очередь очень сильно на любителя. По-моему в случае с десктопом лучше не изобретать велосипед, а использовать всякие общепринятые сиплюсплюсы, кьюты, или вообще дотнеты.
KP>Python обладает более обширной библиотекой (за пределами разработки Web-сайтов) чем Ruby и он слегка шустрее. Я бы не сказал что у Ruby есть какие-то серьезные преимущества, как минимум до тех пор, пока ты Рельсы не хочешь использовать.
Тут снова достаточно возразить, что у Ruby как минимум нет проблем 2 vs. 3, огроменный централизованный репозиторий с кучей библиотек и тот самый, упомянутый вами, RoR. Даже если согласиться, что Ruby и Python примерно одинаковы, окей, почему Python, а не Ruby?
