Комментарии 43
Если бы в нём были фигурные скобки вместо отступов, ему бы цены не было.
Я лично код на питоне не перевариваю чисто визуально.
Почему Python так популярен у инфо бизнесменов в 2025?
Python был в первых рядах и до популяризации машинного обучения, обработки больших данных и т.п.
чему первому студента научили - то и будет популярным.
Когда-то это был Паскаль: бородатые профессора с умным видом писали на доске программу Hello world, попутно обьясняя что такое обьявление переменной, а студенты записывали, и дома начинали писать свои первые программы, на Паскале, естественно.
Прошло время, молодые когда-то аспиранты стали новыми профессорами, и теперь "свою первую программу" многие пишут уже на Питоне.
Так оно и идет.
Посмотрите, какой новый язык программирования зреет сейчас среди аспирантов (Промпт? чем не название? И тоже на "П") - вот это и будет через некоторое время на первых местах, потому что именно на нем студенты напишут свою первую программу...
Наиболее заметным преимуществом Python, которое всегда на виду, остается его читабельность.
def train(model):
for item in model.data:
model.learn(item)Удивительно читабельный, не то что C#:
void train(Model model) {
foreach (var item in model.data) {
model.learn(item);
}
}Go:
func train(model Model) {
for _, item := range model.data {
model.learn(item)
}
}или даже Kotlin:
fun train(model: Model) {
for (item in model.data) {
model.learn(item)
}
}Может быть уже хватит тиражировать сказки про простоту и читабельность Python из 90-тых, когда это действительно было так на фоне других языков? Давно уже наштамповали новые языки и прокачали старые и сам Python уже давно не такой простой и читабельный как раньше.
Благодаря этому команды тратят меньше времени на разбор логики и больше на улучшение функциональности. Ошибки выявляются быстрее. Ревью проходят более гладко. А иногда даже люди без опыта программирования могут понять Python‑скрипты без посторонней помощи.
Можно задать себе интересный вопрос, почему если есть такой чудо-синтаксис, который буквально хорош во всем, подавляющее большинство мейнстримных языков как были так и есть сиподобные?
Добавьте к этому поддержку Python нескольких парадигм программирования (процедурное, объектно‑ориентированное и функциональное), и становится понятно, почему он так популярен, правда?
Нет не становиться. Практически все самые популярные яп сейчас мультипарадигменные, Python здесь вообще ничем не выделяется.
Python популярен потому что низкий порог входа, потому что искусственный интеллект и машинное обучение на нем практически монополизировано а оно сейчас нужно и важно везде, плюс огромная экосистема.
ну пример с Go прям не очень выглядит
Давно уже наштамповали новые языки и прокачали старые и сам Python уже давно не такой простой и читабельный как раньше.
Прокачанные старые языки обычно и не читаемые и своим изначальным принципам изменяют. Питона это, кстати, тоже касается. Новым обычно не хватает раскрученности и экосистема бедная. Go читаемый только в туториалах, так он полон корявых конструкций (= vs :=, " vs ' vs backtick, range, стримы, map[int]struct{...}, []string{"boring"}, слайсы).
Можно задать себе интересный вопрос, почему если есть такой чудо-синтаксис, который буквально хорош во всем, подавляющее большинство мейнстримных языков как были так и есть сиподобные?
Для пыщ-пыщ и в прод отличный синтаксис, для алгоритмов уже не очень. И сишка используется там где скорость важна, если вы на нём api пишете - ссзб. Хз что там с растом, слишком токсичен чтобы было желание туда лезть сейчас.
Нет не становиться. Практически все самые популярные яп сейчас мультипарадигменные, Python здесь вообще ничем не выделяется.
Мультипарадигменность на словах - ну у нас есть классы, ну и функции можно передавать аргументом. Реально же мультипарадигменность измеряется тем насколько легко и гибко писать фреймворки, а тут Питон очень хорош за счёт богатых возможностей сломать язык.
А вот так ещё нагляднее
алг тренировать(модель)
нач
для каждого элемент из модель.данные
нач
модель.обучить(элемент)
кон
конИ актуально, в ногу со временем. С учётом новостей о том, что в Пензенском Государственном Университете будут обучать студентов программированию на кириллице.
В приведённых вами примерах python выглядит наиболее читаемым. Но то что вы их приводите, желая подтвердить противоположную точку зрения, говорит о разнице в восприятии у, как минимум, нас с вами. Т.е во-первых всем не угодишь. А во вторых, возможно, на восприятие влияет длительный опыт использования. Если бы мне доверили решение переходить ли на C подобный синтаксис или оставить отступы, то я бы не сомневаясь ответил "отступы, никаких точек с запятой и, уж тем более, висящих закрывающих фигурных скобок!".
Но то что вы их приводите, желая подтвердить противоположную точку зрения, говорит о разнице в восприятии у, как минимум, нас с вами.
Я не желаю подтвердить противоположную точку зрения, для меня все примеры - одно и тоже. Я оспариваю тезис о том что у Python чудо-синтаксис и благодаря этому он популярен.
После JS Python вызывает отвращение. Аргумент про читабельность весьма мнимый и как мне кажется субъективный, как уже отметили в других комментах (боже где мои скобки). А меня больше всего неприятно поразило, что в Python нет нормального нативного поиска индекса элемента по значению в массиве. Либо как-то криво-косо через filter либо index, который при ненахождении выбрасывает ошибку вместо родного "-1", это лишний try/except, и как же это меня бесило. Возможно, т.к. я имею не особо большой опыт работы с этим языком, да и то только через решение алгоритмических задач (а промышленное программирование это уже почти другая вселенная), у меня сформировалось такое впечатление, что если бы все эти крутые штучки для работы с ML и прочим прочим были бы в другом любом языке (даже не JS, любой сейчас +- популярный взять), то Python бы не имел такой огромный успех. (Все имхо, на правильность абсолютную не претендую)
я всё понимаю но почему нельзя просто писать свои функции по типу индекса?
вот реализация если что:
def index(lis, el):
ind = 0
for i in lis:
if i == el:
return ind
ind += 1
return -1либо же можно писать такие функции:
def my_index(lis, el):
try:
return lis.index(el)
except:
return -1чем же сложно писать функции по типу второго варианта и сделать это в файл с названием по типу utils?
или что вам мешает ещё? объясните.
Тем, что после других языков, ты прямо ожидаешь в стандартной библиотеке определённый набор инструментов.
В питоне в целом подход бросать исключение вместо возврата кода ошибки. Тут можно много спорить что лучше (если исключения типизированы, то я за исключения), но поэтому стандартный index так и делает. И index вообще необязательная функция, потому что лист (массив) не подразумевает поиск по значению, для этого другие структуры используют.
Рад, что получил хороший ответ на свой вопрос). Я не специалист, а лишь только учу python после js, и мне приятно получать такой фидбек. Если в Python действительно есть такой общепринятый подход, то это все объясняет с index (хоть мне он не очень понятен, но раз проверено временем и реальными разработчиками - спорить я бессилен). Спасибо
upd: а какие другие структуры используются?
Из встроенных - dict/set.
a = {10: 20, "qwe": "rty"}
a[10] # 20
a[20] # KeyError
a.get(20) # None, без исключения
Но это хэштаблицы (set - просто множество) с соответствующими асимптотиками. В встроенных библиотеках есть heapq (очередь с приоритетами), collections (там всё подряд - fifo/lifo/deque/defaultdict), мб ещё что полезного. Чтобы прям ассоциативный массов с поиском по любому элементу пары нужно внешнюю библиотеку искать.
Я специально написал нормального нативного поиска. Конечно, собственную реализацию сделать за минуту можно, но хочется иметь это в стоке, особенно настолько базовый функционал.
return x in l and l.index(x)
Возвращает индекс или False.
Это самый короткий способ. Можно чуть длиннее через тернарный оператор.
Что в стиле code golf. Прикольно, коротко, но удачи такое читать с похмелья.
Да не, читаемость как раз ок, просто мысленно скобки поставьте
return ((x in l) and (l.index(x)))
Другое дело, что это два прохода вместо одного и результат с типом None | int.
Для одного прохода (и другой асимптотики) другие структуры есть.
Но читается это тяжело. Не хотел с Вами спорить, но теперь представьте, что это выражение не сразу после return а какая-то логика ещё вокруг него есть. Я бы писал обёртку все же.
Да тут спорить особо не о чём, правы те кто хочет прозрачнее.
Я в личных проектах обычно начинаю с подробных конструкций, а потом сокращаю до пределов своего понимания (привычка с Хаскеля), но в команде по запросу пишу многострочно, конечно. В данном случае, я бы сказал, что если вся команда инженеры со стажем, то могут договорится сокращать. Но если код читает аналитик, которому не до питонячьего сахара, то лучше расписать/обернуть.
А где вам часто требуется index, чтобы так по этому поводу переживать? Много писал на питоне, но чего-то не припомню, что хоть раз в реальном коде использовал. Без наезда, реально интересно
Забавно читать про отвращение от рутнопа после JS. В рутнопе хотя бы 1 + “1” не будет “11”.
Что касается исключений, то потрудись изучить предмет критики. Корни любви к исключениям растут из оригинальной реализации языка: CPython. В ней исключения бесплатные. В том смысле, что всё необходимое для их обработки создается при каждой операции, оборачиваешь ты выражение в try-блок или нет (одна из причин медленности CPython). Это и продиктовало то, что для исключительных ситуаций в языке без раздумий бросают исключение, а не как в некоторых, типа JS, выдумывают обходные пути, вида «вернуть невозможное значение, чтобы просигнализировать о случившейся при выполнении ошибке». И да, отсутствие элемента в коллекции при операции нахождения индекса этого элемента в ней — это исключительная ситуация.
JS после Python, кстати, у меня тоже вызвал отвращение из-за странных особенностей типизации)
Фигурные скобки удобны хотя бы тем, что при просмотре кода, встретив там
if( какая-то хрень) {
....... многабукв .....
}
можно пропустить все эти многабукв простым %, и сразу перейти к следующему блоку, а не перематывать страницу за страницей макаронного кода, высматривая, пока там отступ будет такой же, как был в начале.
Что за синтаксис, в котором лишний пробел способен поломать работу программы?
Что за синтаксис, в котором лишний пробел способен поломать работу программы?
А точка с запятой? А опечатка в константе?
можно пропустить все эти многабукв простым %, и сразу перейти к следующему блоку, а не перематывать страницу за страницей макаронного кода, высматривая, пока там отступ будет такой же, как был в начале.
В 2025 есть language server protocol, treesitter, всякие фолдинги и т.п. Присмотритесь к своей ide.
Python популярен, потому что мудро спроектирован.
Во первых, у Python есть свои Дзен постулаты (import this). С виду шутка, но по сути, установки очень сильные, которые повлияли на развитие языка на всём протяжении времени.
Во вторых, язык пропитан принципом DRY. Это придаёт некоторую однозначность в решении тех или иных задач, набор отличных хорошо известных и поддерживаемых модулей.
Как бы не было много критики про принудительные отступы, как часть синтаксиса, но, это действительно приучает форматировать свой код.
Всё это создаёт некоторый вайб надёжности, практичности и уважения. Я бы далее сказал, заботы.
Конечно, простота языка относительна. Она заканчивается примерно там, где приходится углубляться в мета классы, перегрузку операторов, декораторы, множественное наследование и функциональное программирование. Можно очень изящно написать абстрактный эффективный код, который вы сами уже через два дня не поймёте 😊 Отдельное недоразумение - перекраска функций в async.
Перегрузка операторов, в том числе, позволяет наглядно отображать математические выражения в код, отсюда и. Синтаксис слайсов - туда же.
А так да, в питоне может найти себя как новичек, так и любитель множественного наследия.
Перечисленное в комменте, конечно, по большому счёту не явялется чем-то особенным, и в целом кажется не является хорошим аргументом.
Для оценки мудрости cпроектированности питона не нужно даже спускаться в функциональное программирование и метаклассы — достаточно вспомнить как в питоне работают скоупы и shadowing. Про многопоточность даже упоминать не хочется.
Постулаты это конечно хорошо, но на качество кода они влияют примерно никак, да и сам питон им не особо следует: N видов форматирования строк, несколько способов сделать цикл, особые кейсы для малых чисел, неявные truthy/falsy значения, импорт библиотеки может исполнить код, и прочее прочее.
Уровень пропитанности языка принципом DRY это что-то новое, но питон точно не поощряяет функциональное программирование с обобщённым поведением (потому что писать на питоне в фп стиле это боль). Если под набором модулей имеются в виду сторонние библиотеки, то да, это большое преимущество экосистемы питона, которая развивалась годами, но не питона как языка.
Отступы конечно приучают форматировать код, но не из-за желания разраба сделать красиво, а из-за того что поведение программы меняется. Форматтеры в "языках с фигурными скобками" уже давно научились форматировать код за нас, и кажется добавить 1 шаг в CI для проверки форматрования кода может сэкономить пару нервных клеток.
Не знаю, о каком вайбе надёжности, уважения и заботы идёт речь, в питоне нет каких-то "сложных" концептов а-ля зависимые типы, АДТ, эффекты (и др.) что может вызывать такие чувства. Практичность у питона конечно есть, и обособлена невероятным количеством библиотек на все случаи жизни.
Другими словами, питон практичный язык с кучей библиотек и проблем, которые проявляются на больших проектах.
достаточно вспомнить как в питоне работают скоупы и shadowing. Про многопоточность даже упоминать не хочется.
Многопоточность на заре питона ошибочно казалось ненужной, но главное что GIL всегда признавался ошибкой и почти побеждён (в отличие от Го, которые открыто шлют с обработкой ошибок). Shadowing - интересная тема. На мой взгляд, если вам нужен nonlocal, то вы что-то делаете не так. То есть это решение запутанное, но в реальности в ногу почти не стреляет.
Отступы конечно приучают форматировать код, но не из-за желания разраба сделать красиво, а из-за того что поведение программы меняется. Форматтеры в "языках с фигурными скобками" уже давно научились форматировать код за нас, и кажется добавить 1 шаг в CI для проверки форматрования кода может сэкономить пару нервных клеток.
Опять же история. В 2025 продавать отступы как киллер-фичу питона уже стыдно, но когда CI/CD не существовало - это действительно было глоток воздуха.
а-ля зависимые типы, АДТ, эффекты (и др.) что может вызывать такие чувства.
Вы хаскеллист, верно? Или идрис/кок/агда? На мой взгляд есть некоторый порог промышленного программирования ниже которого некоторые концепции уже невозможны. ADT ещё как-то могут проникнуть вниз, но завтипы, к сожалению, останутся в лабораториях ещё очень надолго. Или навсегда учитывая рост популярности индусских языков. В этом смысле питон стоит достаточно высоко среди группы промышленных языков.
Вы хаскеллист, верно?
Скорее просто питонист, который слишком много пишет на питоне каждый день
Насчёт всего остального, очасти могу согласиться, но это не опровергает изначального тезиса -- питон не был "мудро спроектирован". И то, что гил признаётся ошибкой уже дцать лет, не мешает языку иметь кучу проблем.
Тогда почему по-вашему, Python столь популярен?
практичный язык с кучей библиотек и проблем, которые проявляются на больших проектах
это можно сказать про любые языки и библиотеки без исключения, разве нет?
особенно, если учитывать, что 90% того, что вы используете, написано энтузиастами в свободное время
Питон популярен из-за следующих факторов: 35+ лет существует, много всего встроено в стдлиб, много сторонних библиотек. Плюс-минус то же самое можно сказать про ЖС, но там ещё и куча транспайлеров с других языков, разной степени готовности для продакшна.
Честно, не уверен, что понял второй вопрос.
Сказать можно разное про разные языки. Так же можно сказать, что перечисленное в оригинальном комменте точно не является плюсами конкретно питона, и применимо к другим языкам. Всё относительно, у всех языков свои плюсы и минусы, нужно лишь с холодной головой осознавать эти качества и характеристики.
Разве он не популярен уже лет 8, с тех пор как началась движуха с прикладными нейросетками и биг дата?
Почему Python так популярен в 2025?