Чем плох Python?

Не являюсь питоно-хейтером, сам на нём даже не пишу, самое значительное из плохого — стандартная реализация очень медленная.

Чем он хуже по сравнению с … Ruby

Ruby намного более логичный и консистентный. Всё в стандартной библиотеке устроено понятным, удобным и запоминающимся образом.

На Питоне это просто какое-то постоянное приключение «угадай, что!».

У меня похожие впечатления были только от php. Там тоже автор следовал пути сделать всё не как у всех.

Ну одно другому не мешает. Когда надо - пишем, когда бесит - хейтим.

Чем он хуже по сравнению с Perl, Ruby, Javascript

Ничем. И ничем не лучше.

Алсо, мои темы минуток ненависти к питону:

• Как мне в питоне включить отладочный лог для единственного модуля?
• list comprehensions

Ну и конечно не могу не порекомендовать https://www.linux.org.ru/people/rsync/ как источник лулзов по сабжу.

Лучше перла, ибо живой.

Перл переживает не лучшие времена, но он тоже живой. В Tiobe он посередине между руби и матлабом

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

В Tiobe он посередине между руби и матлабом

Сомнительная жизнь.

Претензии хейтеров к Питону

Не являюсь питоно-хейтером, сам на нём даже не пишу, самое значительное из плохого — стандартная реализация очень медленная

https://habr.com/ru/post/481782/ — это мой обзор проблем питона касательно одной только производительности и поддерживаемости. То есть, даже без анализа всяких сахарков и «лямбды некрасивые». Причем, большинство из этих проблем нерешаемы без переписывания языка со стандартной библиотекой заново. Собственно, с развитием того же asyncio появилась необходимость половину стандартной либы переписывать.

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

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

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

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

Питон сносен для обучения и для мелкого софта.

Javascript

Питон медленнее и это не исправить.

И вообще, в 2к21 есть swift, kotlin, f#. Они лучше питона всем кроме, ситуационно, библиотек.

Почитаю вашу статью, спасибо, что скажете про руру?

Спасибо.

И вообще, в 2к21 есть swift, kotlin, f#. Они лучше питона всем кроме, ситуационно, библиотек

Как бы да, но как бы что в итоге на них можно написать и на чем это потом запускать? У F# адекватная поддержка только на винде (как и у других малопопулярных решений на базе дотнета), Swift и Kotlin имеют аналогичные проблемы с узостью поддерживаемых платформ. А если отрываться от готовых платформ и решений, то можно было бы и на лиспе писать.

Почитаю вашу статью, спасибо, что скажете про руру

Не помню, писал ли я в статье по поводу него, но PyPy — это единственная успешная попытка заставить питон работать быстрее, не переписывая язык заново. К сожалению, JIT-компиляция имеет свою цену, и однократно исполняющиеся строки кода на CPython работают быстрее, чем на PyPy.

Спасибо. Правда, думаю, руру ещё не готов, нигде не читал, про том, как перевести портаж на него.

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

Отвечая самому себе:

PyPy — это единственная успешная попытка заставить питон работать быстрее, не переписывая язык занов

Однако же, таки большинство проблем совместимости PyPy с CPython возникают из-за того, что кучу модулей из стандартной библиотеки пришлось переписывать с Си на RPython. RPython — это язык транслятора и части стандартной либы PyPy, введение которого необходимо для сквозной оптимизации, вроде вывода типов, инлайна, скаляризации векторов-контейнеров, и прочего. Это парадоксально, и в то же время иронично: язык Си является препятствием для оптимизации выполнения питоньего кода.

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

Эти самые «высокопроизводительные библиотеки», в большинстве своюм, и явялются бесполезными костылями, решающими проблемы производительности питона. Pandas, Numpy, а также все связанные с ними интерфейсы в других либах, вроде Tensorflow и Matplotlib — это бесполезные фичи, которые не делают ничего нового, чего нельзя было бы сделать простым питоном. Однако же, в простом питоне это работало бы настолько медленно, что стало бы никому не нужным. Ты просто не представляешь, насколько питон будет медленным, если из него выкинуть всю эту гору ускорений в виде стандартной библиотеки.

нигде не читал, про том, как перевести портаж на него

USE=pypy3 emerge portage

Я не думаю что я хейтер. Я к нему равнодушен. Мало использую чтобы испытывать чувста.

Но я не вижу у него только одно достоинство - легко писать расширения на С и как следствие большая библиотека.

Все остальное хуже чем у Perl и Javascript

Особенно Питон отстаёт от Typescript

Медленный, отсутствие статической типизации

Фичи сокращения кода на перле (всякие дефолтные переменные и проч.) приводят к тому, что на перле пишут скрипты write-only, которые человеку, не писавшему данный скрипт, нужно сначала расшифровать, тем более если он не знаком с перлом. На питоне обычно есть один способ реализации, он может показаться дуболомным и не крипто-изящным, но он обычно понятен с первого раза. Перл привлекает таких дурачков, которые, вычитав, как сократить исходник ещё на один символ, спешат побыстрее применить это знание в своем мега-скрипте. Но это выгодная стратегия, если ты какой-нибудь недоадмин или недокодер, который как паучок в заброшенном сортире, сидит на своем коде, как на паутине, и не хочет, чтобы ещё какой-то паучок-конкурент сходу разобрался в его перлах (какое удачное словесное совпадение!). Эдакий незаменимый для фирмы кадр.

И работает? Если да, то насколько даёт прирост в скорости?

На Питоне сложно писать однострочники. Особенно, с вложенными if-ами и for-ами. Особенно, чтобы было читаемо :)

Не знаю, не пробовал.

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

Спасибо, тогда есть повод поставить калькулейт в виртуалку.

На Питоне сложно писать однострочники. Особенно, с вложенными if-ами и for-ами

Есть онлайн-сервисы для решения этой задачи:

http://www.onelinerizer.com/

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

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

Меня оттолкнуло отсутствие switch, хотя, говорят вроде, уже завезли.

Статическая типизация в языке - это самый жирный минус.

Статическая типизация в языке - это самый жирный минус

Никогда не встречался с ситуацией, что коллега кинул аргументом твоей функции вместо строки криптообъект? Причем, оно еще и работало как-то в таком виде, но через раз. На масштабе 10к+ строк код очень быстро выходит из-под контроля.

Перевести, емнип, можно, но текущий pypy совместим больше с 3.6. А так как его удалили из репы, то было принято решение pypy перевести в testing обратно. В рассылке про это было. Пока не знают как с ним быть.

Чтобы распарсить HTML?

Если человек малограмотный, то да, он может попытаться разобрать КС и сложнее грамматики при помощи конечного автомата без магазинной памяти. А так, да, в неструтурированном тексте искать простые последовательности.

https://blogs.gentoo.org/mgorny/2020/10/06/speeding-up-emerge-depgraph-calculation-using-pypy3/

Как повезёт.

Ага, спасибо, примерно так и думал. Ведь если бы можно было ускорить, как минимум обговаривали это вариант.

https://archives.gentoo.org/gentoo-dev/message/f6d4b380665dcbde3bdfd3a6e3bfdd28

Вот из рассылки про возвращение в ~

Спасибо.

Нормально объяснить чем плох X могут только X-loverы.

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

Вот интереснее всего, что обычно к синтаксически важным отступам в основном имеют претензии люди, которые на данном языке не пишут.

(Эти же люди часто в упор не видят ничего плохого в синтаксисе Makefile’ов.)

Вложенные if’ы и for’ы в однострочнике нечитаемы на любом языке.

Выйти боком, если их не делать? Но зачем их не делать?

Неправильно формулируешь вопрос.

Чем он хуже по сравнению с Perl, Ruby, Javascript

Ничем. Python во всём лучше перечисленного.

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

Основные проблемы: типизация, скорость, GIL. В какой-то мере это решается тайпхинтами, mypy, asyncio и async/await с убодным запуском нескольких инстансов приложений с помощью контейнеризации, либо ProcessPoolExecutor.

На Питоне это просто какое-то постоянное приключение «угадай, что!»

[не] консистентный

Угадываю уже на протяжении более чем 10 лет, и каждый раз успешно. Что я делаю не так?

Питон медленнее и это не исправить

Глупость феерическая. У JS вообще нет референса. А у питона помимо референса есть Cython, PyPy и Numba.

Меня он раздражает пакетными менеджерами. pip устаревший, pyenv оооооочень меееееееедленный и тупой. После npm смотрю на них, как на говно. Ну и скорость огорчает. А так, хороший язык для своих задач.

зато JS просто работает, без костылей и поедания кактуса

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

И да. Я терпеть ненавижу питон. Он совершенно нелогичен, стандартная библиотека выглядит набором рандомных функций. Как выше уже говорили, хуже только в php. Работа с модулями ужасна.

Справедливости ради, де-факто референс есть - V8.