За что не любят Python?

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

Странно, с «мешалкой» или без мне пофиг, а вот без круиз-контроль тяжело.

Не только. У меня прогноз продаж/закупок был сделан на питоне. И вот очередная версия numpy перестаёт сохранять размерность ряда скользящего среднего (и других rolling функций) и обрезает «хвосты». И всё, всё посыпалось

без круиз-контроль тяжело

А что на мешалке можно сделать нормальный круиз-контроль?

Потому что у безработных дельфистов куча свободного времени, вот они и срут другие технологии.

им очень неудобно утилизировать многопроцессорность. рулить тредами в наши дни - «зашкварно».

Собственно, это главное. Почти в любом нетривиальном проекте на Python рано или поздно возникает Celery. А возникновение в проекте Celery - признак того что его нужно было делать не на Python.

Проблема с зависимостями давно решена. Ну, как минимум, лет 6-7 уже. На самом деле, даже дольше.

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

Питон - говно, потому что они делали язык для дебилов и получился дебильный язык. Они сами не понимают, у них язык функциональный или ооп. Почему len - это функция, а не метод/свойство строки/массива? Почему lambda такое говно из жопы? Нет нормального составного оператора? Да, пистонята? Ну и всякое хардкод-говно типа __main__. Убогие не смогли наваять неймспейсы? Сразу сделали говно и только потом дошло? Если у них там был диктатор, то у диктатора в голове была шиза.

Прицепом еще всякие затычки дырок типа range. В нормальных языках, такие вещи обобщают и делают генераторы. Python-way говна - это одна затычка на один кейс. +1 кейс, +1 затычка.

У меня глаз дёргается, когда в 2023 году вижу питоновское «for i in range(len(a))» для обхода списка :)

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

Убогие не смогли наваять неймспейсы?

В Python есть полноценные неймспейсы, __main__ никак к ним не относится, критика вообще не по адресу и довольно бессмысленная.

Если у них там был диктатор, то у диктатора в голове была шиза.

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

Сам Гвидо работал в Google и Microsoft.

Всё это, по-твоему, 100% признаки шизы?..

В нормальных языках, такие вещи обобщают и делают генераторы.

Во-первых, range и есть генератор. Во-вторых, обобщают что именно? В Python ты можешь итерироваться по объектам непосредственно, если они поддерживают протокол итераторов. Можешь использовать генераторы, в т.ч. yield from.

Полагаю, что опять «слышал звон, да не знаю где он».

У меня глаз дёргается, когда в 2023 году вижу питоновское «for i in range(len(a))» для обхода списка :)

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

По спискам можно итерироваться непосредственно, можно использовать list comprehensions, можно использовать yield from.

Даже тогда, когда нужен range(), чаще бывает правильнее и понятнее написать: for i, elem in enumerate(lst).

Просто джуны обо всём этом не знают. ))

Просто погуглил по диагонали «python iterators» и удивился, что там нет аналога рубевского «a.each { ... }»

for el in a:
  do_smth(el)

Разве не то же самое? Или list comprehension.

Ну да, синтакс слегка отличается, но на то ведь и существуют разные языки. Я, например, к Ruby так и не смог привыкнуть - слишком напоминал мне нелюбимый Perl, а также был тормозным и малопопулярным. RoR немного всколыхнули популярность, но ненадолго.

Этот диктатор сделал язык, на котором пишут миллиарды людей в мире

Классика про миллиарды мух.

Да, да, аргументы кончились - пошли мухи.

Я даже не начинал. В этот раз лень холиварить. Уже стопицот раз было здесь и везде доказано, что питон днище. Фанбои все равно будут визжать от восторга благодаря Blub paradox.

Уже стопицот раз было здесь и везде доказано, что питон днище.

Не было. Покажи эти объективные доказательства. В лучшем случае, это что-то вроде «я пытался использовать монитор в качестве санок, но он плохо скользит и сломался, когда я скатывался на нем с горки».

Фанбои все равно будут визжать от восторга благодаря Blub paradox.

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

@Psilocybe поставил рукалицо без объяснений.

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

К пространствам имён эта конструкция не имеет вообще никакого отношения. Не заменяет их, не дополняет их.

@crutch_master просто не знает ни Python, ни того, что такое пространство имён. Можно залезть в список его тем, я точно помню, что он не один раз задавал нубские вопросы по питону.

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

Наезд про генераторы и итераторы тоже оказался нераскрыт.

К чему «рукалицо»?

Ещё раз говорю: в Python есть куча объективных недостатков. Как и у любой технологии, созданной людьми. Но хейтеры почему-то вместо реальных недостатков, придумывают высосанные из пальца, и талдычат о недостатках, которые существуют только в их воображении.

кто?

ок, а если у меня есть несколько списков одинаковой, но неопределённой длины, элементы в которых являются параметрами для вызываемой функции?

В этом случае да - перебор индексов for'ом это самое простое и дубовое решение. Хотя, в «моей прелести» можно вот так:

a = [ 100, 150, 25, 105 ]
b = [ 120, 100, 50, 100 ]

a.zip(b).each { |x, y|
  puts x*y
}

Всё это, по-твоему, 100% признаки шизы?..

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

Во-первых, range и есть генератор

Это не генератор. Это частный случай генератора, как это в пистоне любят.

В Python ты можешь итерироваться по объектам непосредственно, если они поддерживают протокол итераторов. Можешь использовать генераторы, в т.ч. yield from.

Было бы совсем позорно, если бы этого не сделали.

Полагаю, что опять

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

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

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

В чём конкретно проблема с len? Если тебе не нравится len, ты можешь вызывать метод объектов .__len__(), что, собс-но, и делает len.

Допустим, Lisp, Clojure - фукнциональные языки? ОО языки? Может быть, тоже говно и шиза, потому что не укладываются целиком ни в одну парадигму?

А C++? На нём тоже можно писать в процедурном стиле, а можно в ОО-стиле.

Это не генератор. Это частный случай генератора, как это в пистоне любят.

Поясни, что ты имеешь в виду. Что за «частный случай», и чем конкретно плох range?

Ты в одном посте умудрился сделать аргумент к авторитету, толпе, личности

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

Ты вот какашек накидал, но даже не можешь пояснить, что именно плохо.

и проигнорировать самый неудобный вопрос про методы vs функции.

Чем неудобный? Ну вот, выше спросил, отвечай теперь.

какой язык лучше питона

Из современного мейнстрима любой ЯП лучше питона. Если же вернуться в 2003 год, то там питон неплохо смотрится. Где-то в средневековье вы и застряли.

Из современного мейнстрима любой ЯП лучше питона.

Что там, в современном мейнстриме? Можно больше конкретики, пожалуйста.

Такие вещи можно найти в любом языке

И что теперь? Сидеть и делать вид, что всё нормально? Я тебе уже говорил про аргумент к толпе, и тут же «так у всех». Ты не обучаемый. Прочитай про логический ошибки, вызубри их, распечатай, на стенку повешай, чек текста делай, прежде чем постить очередную херню.

Питон не навязывает никакую парадигму, и сразу говорит об этом.

Только функция объявляется там исключительно через def, инлайн объявлений нет, сделать мапу с функциями можно только через жопу. Хочу побаловаться с декларативщиной, нет, хер тебе, пиши как все, делай как все class и не выделывайся.

В чём конкретно проблема с len? Если тебе не нравится len, ты можешь вызывать метод объектов .__len__()

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

Я вообще не понимаю, где здесь проблема.

Проблема в однообразности подходов, да и вообще в однообразности языковой логики.

А C++? На нём тоже можно писать в процедурном стиле, а можно в ОО-стиле.

Можно писать, а можно не писать. А на пистоне нужно писать len и функции создавать через def и похер, что функция - это объект первого порядка.

Поясни, что ты имеешь в виду. Что за «частный случай»

Есть решение задачи в «общем случае» - это генератор. Решив задачу в общем случае ты решаешь любой частный случай этой задачи.

и чем конкретно плох range

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

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

Я немного был знаком, мне хватило.

Потому что кидаться безосновательно

Я кидаюсь основательно, мне не нравится конкретно вот это. Если тебе нечего ответить, не отвечай ничего.

Допустим, Lisp, Clojure - фукнциональные языки? ОО языки?

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

Чем неудобный?

Тем, что ты его сразу проигнорировал, кинувшись воевать с тем, что оспорить проще.

всех слушать неинтересно

Демагогов, типа тебя, тоже нихрена не интересно слушать по существу. Но забавно с другой стороны.

правильно. в питоне тоже так можно:

a = [100, 150, 25, 105]
b = [120, 100, 50, 100]

for x, y in zip(a, b):
    print(x * y)

Только функция объявляется там исключительно через def, инлайн объявлений нет

Да, функция объявляется исключительно через def или lambda, при этом лямбды неполноценные. И что? Это делает язык однозначно плохим? Почему именно - потому что лично тебе это не нравится?

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

Сделать словарь с функциями можно легко, куча питон кода использует этот подход, включая стандартную библиотеку. Да, функции придётся определить заранее. Я ни разу не вижу здесь проблемы. Да, в каком-нибудь другом языке можно было бы использовать анонимную функцию, определённую здесь же. Но в 99% случаев — это субъективный вопрос вкуса, не более.

__len__ выглядит как говно, например. Да и вообще любой __ххх__ выглядит как говно, а не как нормальный код.

Возвращаясь к твоему списку логических ошибок: ты просто набрасываешь субъективные суждения. Выглядит. И что, мне может быть не нравится, как выглядит нагромождение {} в Javascript. Но я не называю это недостатком Javascript, потому что понимаю, что это субъективно.

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

У Python довольно чистый глобальный неймспейс и разработчики с большой неохотой добавляют туда что-либо. Ну есть там len, и что с того? Что в этом криминального то? То, что можно было в языке всё сделать объектами?

Ну так сейчас и так всё является объектом в Python. Однако в первых версиях, это было не так, и len, вероятно, артефакт от первых версий.

Любой язык эволюционирует и вынужден поддерживать совместимость с прошлыми версиями. Если бы в Python 3/4 убрали бы len, то позволь предугадать, что ты первый ринулся бы с воплями на амбразуру: «Криворукие пистонщики сломали совместимость!».

Ладно, допустим, len - ужасно уродливая вещь, которая как бельмо на глазу у перфекциониста.

Это делает Python говном? Вот правда, настолько важная проблема?

А C++? На нём тоже можно писать в процедурном стиле, а можно в ОО-стиле.

Можно писать, а можно не писать. А на пистоне нужно писать len и функции создавать через def и похер, что функция - это объект первого порядка.

В C++ десятки стандартов, там можно писать как бог на душу положит. И так, и эдак, а лямбд там до недавнего времени не было. Можно в императивном процедурном стиле. Можно на шаблонах функциональное метапрограммирование развести. Только ни разу не слышал, чтобы именно за богатство выбора подхода к решению задачи его критиковали.

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

Кто пихает везде, зачем пихают везде? Какие ваши доказательства? Да, range - затычка под конкретный кейс, тоже из тех времён, когда Python был молодым, и не было другого способа.

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

Что касается вызова функций, скорости, и т.п: Python не язык для скорости работы в runtime, Python - язык для быстрой разработки. И здесь с ним мало кто сравнится.

Ладно, допустим, len - ужасно уродливая вещь, которая как бельмо на глазу у перфекциониста. Это делает Python говном?

Да. За столько версий могли бы уже избавиться, всё равно никакой обратной совместимости нет.

Я, например, к Ruby так и не смог привыкнуть - слишком напоминал мне нелюбимый Perl, а также был тормозным и малопопулярным. RoR немного всколыхнули популярность, но ненадолго.

Каково это спорить с пайтоно-хейтерами про отступы и прочее обвиняя хейтеров в некомпетентности и стереотипности, а потом самому попасться на подобном?

Ruby по скорости не отличается от Python, где-то чуть быстрее, где-то чуть медленнее.

Вот бенчмарки пятилетней давности Ruby 2 vs Python 3: https://web.archive.org/web/20180705044315/https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/ruby.html

Не говоря уже о том, что два года назад в Ruby 3.1 появился при помощи GitHub и Shopify настоящий JIT, и в скорости он добавил где-то так: https://speed.yjit.org/ А в версии 3.3, которая выйдет в декабре, JIT станет ещё более быстрым, судя по preview версии.

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

Ruby по скорости не отличается от Python, где-то чуть быстрее, где-то чуть медленнее.

Я говорю конкретно про Ruby начала 2000-х, когда я ещё не определился, на каком языке писать. Я тогда и на Perl достаточно много писал.

В то время, Ruby однозначно сливал по скорости Python. Я не знаю, в каком году Ruby начали оптимизировать по скорости работы, но явно не ранее 2010-х.

Сейчас не смотрю, т.к. неинтересно и нет никакого смысла. Работы на Python - валом, и становится только больше, сам язык мне нравится, и если уйду с него, то только в что-то дающее радикальные преимущества, например, по скорости работы (например, играю с Rust).

JIT сейчас есть в Python благодаря PyPy. На некоторых нагрузках (на всех?) PyPy в 7 раз быстрее CPython. Для тех, кто не хочет PyPy, в похожую сторону движется сейчас и CPython. Каждая новая версия приносит очень серьёзные оптимизации. Например, некоторые проекты при переходе на CPython 3.11 получили 25-30% ускорения.

В начале 2000-х в постсовке про Ruby знали полтора человека и я сомневаюсь, что им были вы. А первые две переводные книги по Ruby появились в 2008. Поэтому, я думаю, вы ретроспективно выдумываете.

В Python тех годов ООП было таким неполноценным, что без слёз смотреть было нельзя, а Ruby даже в первой версии, частично наследуя Smalltalk, был полностью ООП языком, поэтому во времена первой версии он уступал в скорости второй версии Python, но за счёт вышеуказанного отличия имел другие преимущества, которые позволяли без боли использовать метапрограммирование и писать любые DSL на каждый чих.

Поэтому в те времена Ruby ещё более походил для утверждения Python не язык для скорости работы в runtime, Python - язык для быстрой разработки. по сравнению с Python.

Или спустя несколько постов что-то радикально поменялось в ваших представлениях?

В начале 2000-х в постсовке про Ruby знали полтора человека и я сомневаюсь, что им были вы. А первые две переводные книги по Ruby появились в 2008. Поэтому, я думаю, вы ретроспективно выдумываете.

Давайте не будем думать за других. Я начал писать на Python где-то в 1998-1999 году. Находясь и работая в России. Чаще для себя, но иногда впихивал утилиты на Python в рабочие проекты.

Затем я устроился в компанию (ныне не существующую), где работали энтузиасты Python, и многое в ней делал на Python. В частности, сайты на Zope и на Plone. Всё это начиная где-то в 2000-2001 года.

Также знал ещё компании и отдельных энтузиастов Python в России. Хотя тогда нас были единицы. Naumen, кажется. Хотя сейчас, это либо другая компания под тем же именем, либо они радикально сменили область деятельности.

Отсутствие книг на русском мне совершенно никак не мешало - тогда на русском вообще не было книг ни о чём, кроме Паскаля, Java, C и C++. В том числе, о Perl, который тогда был очень популярен, а первые книги о нём на русском вышли спустя несколько лет, когда его популярность уже пошла на спад.

Тот же Perl Book, по-моему, вообще никогда не перевели, хотя здесь на ЛОР есть человек, который предлагал мне его перевести. И что?

Я и на ELisp писал тогда несложные вещи. По нему вообще никогда ничего на русском не публиковалось. И что? Я не мог о нём знать или его знать? Непонятная мне логика.

Или спустя несколько постов что-то радикально поменялось в ваших представлениях?

Нет, я просто никогда не видел необходимости для себя изучать Ruby. Для этого было много причин, включая медленность Ruby в те времена, и просто идиосинкратическая нелюбовь к его синтаксису, который напоминал мне Perl (да и сам автор Ruby, по-моему, в те годы говорил, что его вдохновлял Perl).

Ничего не поменялось. Скажем так, в 2000-е года не было никакой мотивации изучать Ruby. Почти как и Python, но на Python всё же тогда было много чего написано, включая множество системных утилит во многих дистрибах, а на Ruby - вообще ничего. Но Python мне понравился, я тогда не анализировал предпочтения, просто понравился синтаксис и коммьюнити.

Потом уже не было необходимости менять Python, который устраивает всем, кроме, скажем, скорости и типизации (и то, с большими оговорками), на Ruby, который помимо тех же недостатков, ещё и является намного менее популярным языком (меньше батареек, меньше работы, и т.д.).

Понятно, GitHub начали писать на Ruby в 2007, а вашим, очевидно, более высоконагруженным проектам в те времена не хватало производительности и вы выбрали Python. Но с другой стороны для вас скорость не главное, а главное скорость разработки.

У вас либо раздвоение личности либо вы противоречите сами себе.

просто идиосинкратическую нелюбовь к его синтаксису

Но Python мне понравился, я тогда не анализировал предпочтения, просто понравился синтаксис и коммьюнити.

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

Я начал писать на Python где-то в 1998-1999 году. Находясь и работая в России. Чаще для себя, но иногда впихивал утилиты на Python в рабочие проекты.

Затем я устроился в компанию (ныне не существующую), где работали энтузиасты Python, и многое в ней делал на Python. В частности, сайты на Zope и на Plone. Всё это начиная где-то в 2000-2001 года.

Что и требовалось доказать. Первая книга не на японском, а на английском по Ruby вышла в 2001 году, когда, согласно вашим словам, вы уже 3-4 года писали на Python.

Понятно, GitHub начали писать на Ruby в 2007, а вашим, очевидно, более высоконагруженным проектам в те времена не хватало производительности и вы выбрали Python. Но с другой стороны для вас скорость не главное, а главное скорость разработки.

Не понимаю, что ты пытаешься доказать, кому и зачем. Я вообще написал, что «Python - язык для быстрой разработки», я не написал, что это важно конкретно для меня.

С настоящим highload я столкнулся как раз где-то тогда, в 2007. И сразу же понял, что это комплексная проблема, и от одной только скорости языка здесь далеко не всё зависит. И до сих пор мне хватает скорости Python даже в 99% highload задач. Потому что можно оптимизировать алгоритм, можно оптимизировать базу, можно накидать больше шардов.

Я всего лишь сказал, что в Ruby мне в том числе не нравилась низкая скорость. Это не было ни главным, ни решающим недостатком.

В мире есть тысячи ЯП, из них десятки более-менее популярных. Я никогда не выбирал язык всерьёз: «Сейчас составлю большую таблицу всех языков, с плюсами и минусами каждого, и начну выбирать».

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

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

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

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

Работа над скоростью Python идёт, в версии 3.11 его ускорили на 20-30%, и это не предел. PyPy работает в несколько раз быстрее CPython. Вот и всё, что я сказал.

При этом, меня даже без PyPy в 99% случаев устраивает скорость Python.

Что и требовалось доказать. Первая книга не на японском, а на английском по Ruby вышла в 2001 году, когда, согласно вашим словам, вы уже 3-4 года писали на Python.

Доказать что? Чувак, ты уже сам с собой разговариваешь.

Я тебе писал лишь то, что начал писать на Python (не на Ruby, или чём-то ещё) до того, как вышла первая книга на русском о нём. Я вообще за свою жизнь не прочитал ни одной книги о Python как языке. Изучал по встроенной документации, спискам рассылки (comp.lang.python в 1999-2000), и т.д. К тому моменту, как стали доступны книги по синтаксису и stdlib Python, они мне были не нужны, я бы уже сам смог такую написать.

Чувак, у тебя подгорело

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

Потому что прекрасно понимаю, что ничего нового он мне не даст.

Сейчас, возможно и нет, но именно попытки Django приблизиться к гибкости и удобству Ruby on Rails столкнулись с ограничениями Python (особенно в плане метапрограммирования и ООП), ради разрешения которых и появилась значительная часть изменений в Python 3.

Так что Python-комьюнити это дало многое, пусть и не совсем явно.

Таже самая история, кстати, и с PHP 7/8 и Laravel.

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

На этом диалог можно и закончить :)

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

Во-первых, ты - это новый неписаный стандарт де-факто общения в Интернете. Можно в любую компанию прийти, и тебе сразу же скажут: «У нас в компании принято общение только на ты». Сначала мне было некомфортно, потом привык. Во-вторых, я принципиально общаюсь на «ты» с людьми, которые называются никами, а не настоящим именем. Я не знаю, кто такой OSBuster, и никогда не узнаю. Поэтому пишу «ты». Если бы было подписано «ИванСидоров», тогда писал бы на «вы», если бы не было иной договоренности.

К подгоранию это не имеет отношения.

Сейчас, возможно и нет, но именно попытки Django приблизиться к гибкости и удобству Ruby on Rails столкнулись с ограничениями Python (особенно в плане метапрограммирования и ООП), ради разрешения которых и появилась значительная часть изменений в Python 3.

Не знаю, не уверен. Где об этом можно почитать? Я не видел никаких радикальных изменений в Django после перехода на Python 3. А в коде Django я копаюсь и даже чуточку контрибьютил.

На этом диалог можно и закончить :)

У тебя нездоровый фетиш на книгах, судя по первому сообщению. То, что я не читал книг о синтаксисе Python, не значит, что я не читаю книги вообще. Например, конкретно сейчас читаю «High Performance Python».

Просто пытался тебе объяснить, что изучить язык можно не читая книг на нём, ни на каком языке. Вот Гвидо, например, написал язык Python, но он до этого не прочитал ни одной книги о Python.

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

zip ?

Ясно/понятно.

Многим нравится, что boilerplate сведён к минимуму (хотя в пределах его применимости на Bash обычно выходит ещё короче).

Вкачусь в холивар на правах питониста. Ненавидят за:

• легаси в языке (нужда в датаклассах, len() vs .len)
• легаси в операционках, когда нужно аж несколько питонов сразу, pip install постоянно ставит не туда и народ не знает как это лечить
• ломкость pip install, когда пакеты приходится собирать самим, а таких пакетов очень много
• невозможность делать сендбоксы, в отличие кстати от lua/js
• довольно сложную систему модулей, где поиск идёт по sys.path до первого найденного __init__.py, нельзя просто взять и импортнуть файл через путь в файловой системе (хотя казалось бы, язык скриптовый)
• GIL (нужно излишне повозиться чтобы задействовать больше ядер)
• динамическую типизацию
• typing как её следствие (эдакий картонный бронежилет, позволяет разве что меньше читать код)
• цветность асинхронности (всё надо переписать на aio-NN)
• низкую скорость (причём система типов легко расширяется, даже на си, и оптимизировать всякие аллокаторы из-за этого крайне сложно)
• невозможность компилировать бинарники без боли (не знаю почему топикстартер утверждает обратное)
• невозможность эффективно скрывать исходный код
• противоречие недавних изменений зену питона
• невозможность многострочных лямбд в синтаксисе (лямбда это выражение, а внутри выражения нельзя делать стейтменты)
• зоопарк реализаций разной степени тухлости
• вроде бы живы ещё те, кто ненавидит переход с 2 на 3

(Дисклеймер: дальше мои догадки, могу ошибаться) Бесконечно можно критиковать, но что у нас есть взамен? Ничто так хорошо не склеивает разнообразный сишный код, как питон. Голанг, жс, луа требуют высокую строгость в стдлибе, чтобы не сломать их внутренний особенный рантайм и гарантии с обещаниями (у голанга свой эвентлуп, хорошие движки жс сложно куда-то встроить, луа здесь наиболее приветливый к встраиванию, но у него стдлиба крайне скудная, и вроде бы это даже фича). Руби это практически тот же питон, только в профиль, с теми же проблемами. Другие языки, которые могут склеиваться со всем миром, имеют куда более высокий порог входа (C/C++/Rust/etc) и с ними в целом сложнее/труднее работать, нужно постоянно пересобирать. Возможно Julia когда-нибудь потеснит питон, но это не точно. Забавно читать как тут с башем сравнивают, на баше писать что-то серьёзное, требующее типов и структур данных это большая боль.

Haskell

Так это же говно для дрочил) Тебе видимо просто нравится нюхать свой пердеж из бокала и говорить всем что кодишь на Haskell. В прод его на расстояние пушечного выстрела никто не пустит.

https://www.youtube.com/watch?v=dNi__BckudQ

легаси в операционках, когда нужно аж несколько питонов сразу, pip install постоянно ставит не туда и народ не знает как это лечить

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

Руби это практически тот же питон

Руби скорее правильный питон (или перл, а в некоторых редакциях наверное даже правильный lua) — но со страной происхождения ему не повезло. Многострочные лямбды и синтаксис без отступов, нормальный HERE DOC.

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

За руби обидно короч.

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

400 каментов, а вот существует мнение, что нормальные люди не устраивают срачей за фирму молотка для гвоздей. @windows10?

Масштабируемых сетевых серверов и фреймворков есть множество. YouTube был сделан на Python (на чём сейчас выполняется, не знаю, но подозреваю, что значительная часть на нём и осталась). Instagram сделан на Python. Новые Meta Threads напсаны на Python.

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

Там нужно одновременно хорошо уметь в многопоточность и уметь в корутины или что-то навроде этого

Там или WSGI/ASGI перед сервером на питоне или супервизор, который запускает нужное количество экземпляров сервера. Поэтому асинхронность там не для сетевых функций.

Серверные фреймворки на питоне так же хорошо укладываются в serverless-функции, как и фреймворки на других языках.

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

Вот тут ругаются как раз В Gimp завезли AI (комментарий)

Вполне допускаю, что сам питон не причем (хотя куча версий и отсутствие обратной совместимости напрягают), просто из-за низкого порога входа и распространенности для всякого «вхождения вайти» кривые руки криворучат.