Комментарии 96
"Гвидо придумал не использовать фигурные скобки или специальные блоки для группировки операторов, а применять отступы"
Уже только за это можно было бы расстрелять автора.
Причина?
Символ табуляции и 4 пробела одинаково подходят к отступу. Но в разных редакторах и системах - табуляция приводит к 8 пробелам. Кроме того, в третьей версии никто не мешает тебе сделать ОГРОМНЫЙ КАК АЙСБЕРГ ОТСТУП. Можно использовать только 4 пробела, но когда ты подключаешь либу, тебе придётся проверить код на символы табуляции, причём одними только глазами ты их не отличишь. И табуляция и пробелы могут быть перемешаны.
не могут, код не запустится
В современной разработке это не столь актуально, линтеры стандарт де-факто в любом проекте. И, при большом желании, смена конфигурации отступа и переформатирование автоматическое.
этим высказыванием вы скорее подтвердили мысль предыдущих комментаторов: Python'ом оказалось не так удобно пользоваться для малой автоматизации, как преподносится в статье - вместо копипасты в консоль сервера какого-нибудь сниппета/фрагмента для одноразовой задачи с правкой под ситуацию дэфолтным редактором, крайне желателен умный настроенный редактор, а то и IDE или автоматизированный процесс сборки.
С этим сложно спорить, использование языка программирования без умного редактора \ IDE сопряжено с неудобствами. Честно говоря, не уверен что у Python тут существенное отличие от других языков, но, как справедливо заметили в этом комментарии - это уже вкусовщина и bikeshedding.
Так это не проблема отступов. Это проблема, что табы разрешены. Гвидо упоминал, что это ошибка, надо было их запретить.
Когда ты подключаешь либу, проверять ничего не требуется. Во всяком случае я не проверяю пробелы, смысл? Может проблемы бывают, но не сталкивался.
Если я вас понял, проблемы только у тех, кто специально косячит, смешивая с табами и ставя их 8 символов. Специально косячить можно в любом языке.
Хороший программист всегда держит код в порядке. Порядок - это прежде всего чёткая структура при оформлении. А в питоне тебе предлагают использовать невидимые символы для оформления кода. Только вдумайтесь в это! Хороший программист всегда контролирует свой код. Как можно контролировать то, что ты просто не можешь увидеть?
Вы, конечно, скажете про всякие доп. штуки для контроля отступов. А я отвечу, что все эти дополнительные инструменты для контроля невидимых символов - это костыли, которые созданы для решения изначально искусственно созданной проблемы.
Нет, код не читается легче. При использовании единого code style в команде нет проблемы чтения кода с теми же фигурными скобками.
Нет, код не пишется быстрее. Во-первых современные IDE автоматически создают блоки в большинстве случаев. Во-вторых хороший программист не является оператором по набору текста и ему платят за то, что он думает. А следовательно, даже если бы IDE не дополняли код, то на блоки тратилось бы какое-то незначительное время на фоне обдумывания решения.
предлагают использовать невидимые символы для оформления
☑ отображать непечатаемые символы.
Да, как я и написал выше - костыли для решения искусственно созданной проблемы. Хороший программист пишет код, а не оформляет дипломную работу в Word соблюдая все требования по отступам.
Если программист не умеет в CodeStyle, то у меня бы возникли сомнения в его "хорошести".
Уже ответил комментатору ниже, что не нужно путать пробелы для оформления кода с требованием использовать определённую последовательность невидимых, отличающихся между собой символов. В питоне без правильной последовательности программа просто не будет работать.
Как ревьювер, я бы очень хотел, чтобы программа на c++ не собиралась, если бы разработчик намешал пробелов с табами. Но сейчас приходится прикручивать для этого сторонние инструменты.
В конечном итоге в масштабах проекта и рабочий код и форматирование и пробелы/табы, как одно из правил форматирования - это требования. Так зачем проекту собираемый код, не отвечающий всем необходимым требованиям?
Перечитайте, пожалуйста, мои комментарии по этой теме. Я уже устал объяснять, что проблема не в code style, а в том, что невидимые символы являются частью языка. В этом и заключается требование, о котором я говорю. Вы либо намеренно это игнорируете, либо просто поспешили мне ответить.
Я нигде не говорил, что не нужно соблюдать code style, который установлен в команде.
Вы не можете увидеть пробелы? Длявасэтоттексттакжевыглядит,какспробелами? Извините за сарказм, но это какой-то гипертрофированный контроль. Я пробелы контролирую глазами, не сложнее, чем фигурные скобки (проще, на самом деле, попробуйте).
Скорость написания кода не зависит, вы правы. Но визуально удобнее. Во всех языках, что я использовал, делают отступы для визуального удобства. Плюс скобки по требованию языка. Без отступов слева код выглядит, как мусор. Так что претензия, видимо, не к наличию отступов, а к отсутствию скобок, на которые вы ориентируетесь. Лично я ориентируюсь на отступы в любом языке, предпочитаю, что бы скобки совпадали с отступами.
Вы не можете увидеть пробелы?
Во всех языках, что я использовал, делают отступы для визуального удобства.
Мне кажется, что вы смешиваете использование пробелов для работоспособности программы и использование пробелов для оформления кода. Напомню, что в питоне бьют по рукам за неправильную последовательность невидимых символов. Причём один невидимый символ может отличаться от другого (таб и пробел), и вы не увидите этого, пока не добавите костыль в виде отображения невидимых символов.
В тех же языках с C-подобным синтаксисом нет такой проблемы. Я могу использовать табы и пробелы где захочу, и при этом программа будет работать.
в питоне бьют по рукам за неправильную последовательность невидимых символов.
Да в любом языке бьют, если команда разработки хорошая. Какая разница, компилятор или линтер?
Но если вы один работаете и можете форматировать как угодно, каждый день по разному, тогда для вас разница есть, конечно.
Проблема не в оформлении кода, перечитайте, пожалуйста, мои комментарии. Я нигде не писал, что не нужно соблюдать code style команды. Я писал о плохом решении в виде невидимых символов, которые являются частью языка.
Если соблюдать code style, то табов не будет. Тогда не будет никакого смешивания. А размер отступов виден хорошо, не видна только разница между пробелом и табом.
Сделать размер отступа частью языка - это хорошее решение. Это само по себе заставляло использовать code style даже тогда, когда не было так модно.
они только для вас не видимы, для остальных с кем вы дискутируете видимы
В редакторе можно включить отображение... Не пайтон, но тем не менее.
Конечно можно, но посмотрите, сколько лишних символов сразу появилось на экране. Очевидно, что визуально воспринимать код стало сложнее. Как я и писал выше - это костыль. Сначала проблема создаётся, а потом придумываются дополнительные инструменты для решения этой проблемы. Так не должно быть.
Конечно можно, но посмотрите, сколько лишних символов сразу появилось на экране. Очевидно, что визуально воспринимать код стало сложнее. Как я и писал выше - это костыль.
Просто на скриншоте выше цветовая схема выбрана не очень. Отображение невидимых символов многие включали давно и в других языках с фигурными скобками. С нормальной цветовой схемой подсветки проблем с чтением не возникает.
В данном случае точками помечаются только пробелы в конце строки. Табов тут нет, но помечаются они чуть по другому.
Включать символы форматирования текста (пробелы, табуляции) в структуру языка программирования - это ад и ужас.
А какие проблемы? Я видел код на других языках, где в одном файле смешивали отступы табами с пробелами, вот это действительно ад и ужас.
Скорее наоборот. Заставляет соблюдать форматирование. Никаких споров в команде, мол, хочу по-другому форматировать (как бывает в других языках). Проблема только в табах, их стоило запретить.
посмотрите, сколько лишних символов сразу появилось на экране. Очевидно, что визуально воспринимать код стало сложнее
Собственно, фигурные скобки — такие же лишние символы, которые создают бесполезный визуальный шум.
Немало людей рассказывают про какие-то невероятные проблемы с отступами в питоне, но я лет за 10 работы с ним не сталкивался ни с одной из них. Не, вру! Однажды пришлось скопипастить сниппет из какого-то всратого блога, где были поломаны отступы и подсветка и переносы строк, из-за чего код склеился — быстро расставил вручную и запустил. Заодно убедился, что мне руткит не поставят )
Единственная проблема, которая реально существовала — смешение табов и пробелов. Но сейчас, когда все пользуются пробелами такой проблемы больше нет.
А зачем? Размер отступа и так виден, без точек.
Я питон только эпизодически использую, ну может раз в квартал, и как только скрипт чуть усложняется, то я постоянно на эти траблы с отступами натыкаюсь. То после копипастинга откуда-нибудь всё съедет, то табы с пробелами перемешаются (а я адепт табов), то я просто "не вижу" где блок начинается и заканчивается. Для тех же кто привык и постоянно в питоне работает, то норм, а я, воспитанный на паскале, вот чуть ли не пальцем по экрану вожу иногда чтобы понять. Дело привычки, на самом деле, но я заметил, что подсознательно стараюсь вообще без глубоко вложенных структур обходиться.
Известная шютка, что использование отступов для логической структуры языка сразу делит всех программистов на две части - кому это сразу нравится, и кто это искренне ненавидит...
И обсуждение этого не может закончится ;)
Одинаково люблю программировать и на C/C++ и на Python. Со мной что-то не так?
Постоянно обсуждаются такие мелкие, но всем очевидно понятные вопросы, самый что ни на есть байкшеддинг. Отступы vs скобки/разделители, camelCase vs underscore_separation, с 0 или с 1…
А по сути это всё совершенные мелочи в языке, другие факторы намного важнее.
А можно перечислить, какие?
Интересно же...
Наличие генераторов в Python, полноценные замыкания, великолепные библиотеки (numpy, pandas), неограниченные целые из коробки.
И не поспоришь! 😁
Ограниченные машинные типы есть. Я написал про вещи, которых мне не хватает в C++ после Питона. Генераторы позволяют отделить итерацию от обработки данных - удобная абстракция, влияет на дизайн кода. Великолепные библиотеки написаны на C/C++, но всю свою мощь проявляют в сочетании с удобным синтаксисом языка.
Генераторы — это просто частный случай сопрограмм. Ленивыми списками генераторы не являются просто потому что они не являются списками.
Кстати, что такое коданные? Что-то в сети "гуляет" только рекурсивное определение, которое нихрена не определяет.
Или можно поиграть в игру: вы мне код на питоне, а я вам соответствующее генерирующее список (возможно, бесконечный) выражение.
Вот, держите:
def foo(path):
with open('readme.txt') as f:
while (line := f.readline()) is not None:
bar = send_some_http_request_and_get_result(line)
yield barКак-то так, если я ничего не перепутал.
А потом можно наоборот: я вам, например, дам ленивое и бесконечное дерево, а вы попробуете написать генератор, выдающий что-нибудь эквивалентное.
А давайте наоборот, я пишу выражение на Хаскеле, а вы пытаетесь напрямую переложить его на генераторы?
fibs = 0 : 1 : next fibs
where
next (a : t@(b:_)) = (a+b) : next tВыдавать что-то эквивалентное я умею, а вот как на генераторах выглядит аналог t@(b:_) — не представляю.
Не сказал бы, что развитая, есть минимум два несовместимых метода проверок - mypy и pycharm. И для numpy типизация не до конца работает.
Это вы статические систему типов привели, к тому же "навешанные" сбоку. А вот динамические типы в Питоне очень даже развиты (фактически, именно эта развитость и убивает любые попытки сделать работающие статические типы или хотя бы нормальную оптимизацию, такая вот ирония).
Хуже того, именно очень сильная и гибкая система динамической типизации очень сильно убивает производительность (не уверен, но возможно что даже сильнее, чем компиляция в байт-код).
Один из важнейших шагов при работе с теми же Cython/Numba - жестко зажать входные типы, чтобы получить максимально эффективный машинный код.
В питоне самое печальное, и почему я несколько лет назад слез с него — скорость. Либо свободно пользуешься фичами языка, классами/структурами/..., но имеешь крайне медленный код — либо старательно укладываешь свою задачу в рамки всяких numpy и pandas, получаешь относительно быстрый код, но теряешь расширяемость и выразительность.
Других недостатков тоже много, конечно, но это прямо решающий.
Упомянутые в комментарии stan_volodarsky
Наличие генераторов в Python, полноценные замыкания, великолепные библиотеки (numpy, pandas), неограниченные целые из коробки.
тоже важные факторы при выборе языка, хотя какие-нибудь неограниченные целые нужны редко.
Благо, сейчас это всё где уж только не присутствует, никак не уникальная особенность питона.
Ты получил архив из пары файлов, главный файл которого содержит следующий исходник, с сообщением: "не запускается" (но ты переспросил, компилируется успешно на любой свежеустановленной убунте). Твои действия? Почему?
#include "stdio.h"
int main() {
printf("Hello, World!\n"); hijack_passwords_and_credentials();
return 0;
}
Ты получил следующий исходник на код-ревью. Твои действия? Почему?
enum VERY_IMPORTANT_ENUM {
A,
B,
C,
};
struct some_data_struct {
int field_a;
char*field_b;void*field_c;
};
Тогда уж Лендина (The Next 700 Programming Languages). Правда ему и тогда уже предъявляли претензии по-поводу отступов в программах:
Naur: Regarding i n d e n t a t i o n , in many ways I am in s y m p a t h y
with this, but I believe t h a t if it came about t h a t this notation
were used for very wide communication and also publication, you
would regret it because of the kind of rearrangement of manu-
scripts done in printing, for example. You very frequently run
into the problem t h a t you have a wide w r i t t e n line and then
suddenly you go to the Communications of the ACM and radically,
perhaps, you have to compress it. The printer will do this in any
way he likes; he is used to having great freedom here and he will
foui up your notation.
Landin: I have great experience with this. (Laughter) I t h i n k
I am p r o b a b l y the only person who has run through three versions
of the galley proofs for the Communications of the ACM.
Университет Амстердама + двухнедельные рождественские каникул = Monty Python - Что было в голове у Гвидо
Например, Гвидо придумал не использовать фигурные скобки или специальные
блоки для группировки операторов, а применять отступы. Эта идея пришла
из ABC.
А туда, возможно, из статьи 66 года про ISWIM.
кто использует его со сторонними библиотеками:
Язык — это самая фундаментальн
уюая часть программного обеспечения, которая объединяет приложения. Обычно язык меняется медленнее всего.
А зачем? Если это для удобства когда есть длинные функции и поставив курсор у одной скобки, чтобы выделилась скобка на другом конце, можно это делать в комментариях:
Ради "шоб було" или для выделения блоков кода? Вопрос без подковырки, мне правда интересно, в каких случаях скобки могли бы быть полезны
7 – 1
Хитрый автор пишет латиницей
По-моему в настоящее время Python переоценен. Есть большое количество языков со статической типизацией (C#, Kotlin), код на которых будет выглядеть так же лаконично, как и код на Python. Но при этом программа на них не будет так дико тормозить, поэтому переписывание на что-то более быстрое не понадобится.
Как с порогом входа или использованием языка в качестве первого и учебного?
Есть ли аналоги python notebook, как легко подружить язык с научными библиотеками, написанными на фортране в бородатые годы и хипстерскими прототипами новой активаторной ф-ции или конфигурации нейронной сети?
Как легко реализовать динамические выпердени, например, хуков на импорты, метаклассов, переопределение встроенных ф-ций, изменение синтаксиса декораторами или добавление хвостовой рекурсии?
Groovy, вроде, пытался во многое из того, в чём приуспел python, но сейчас скорее мёртв, чем жив.
Сорри за глупые вопросы: как в этих языках с асинхронщиной, в C# неплохо, а в остальных?
Неплохо, в Kotlin есть корутины. Ну и это точно то, что нужно изучать новичкам? Довольно сложная концепция, даже профессионалы нередко неправильно пишут асинхронный код.
Как с порогом входа или использованием языка в качестве первого и учебного?
Тоже неплохо. В C# с 9 версии можно писать программы без класса и точки входа: Top Level Statements. В Котлине нужна только точка входа. Если бесят типы, то они почти всегда выводятся автоматически.
Есть ли аналоги python notebook, как легко подружить язык с научными библиотеками, написанными на фортране в бородатые годы и хипстерскими прототипами новой активаторной ф-ции или конфигурации нейронной сети?
Насчет научных библиотек не знаю, не углублялся. Насчет фортрана — а это тоже точно новичкам требуется? По-моему это уже какой-то более продвинутый уровень.
Как легко реализовать динамические выпердени, например, хуков на импорты, метаклассов, переопределение встроенных ф-ций, изменение синтаксиса декораторами или добавление хвостовой рекурсии?
В C# есть динамический тип, все остальное честно говоря выглядит как антипаттерны, костыли или то, чем должен заниматься компилятор (оптимизация хвостовой рекурсии). Во зачем нужно переопределять встроенные функции? Либо я не очень понимаю о чем идет речь.
Groovy, вроде, пытался во многое из того, в чём приуспел python, но сейчас скорее мёртв, чем жив.
Ну C# и Kotlin умирать не собираются. Насколько помню, груви тоже был динамическим, смысла в этом не особо много.
python используется в нескольких сферах: обучение программированию, научные вычисления, написание бекэндов, машинное обучение, скрипты для администрирования системы/автоматизации умного дома с помощью raspberry.
Это разные сферы, я спрашивал насколько предложенные языки могут заменить python в любой из них. Новичкам, наверно, учить асинхронщину сразу не стоит, но вот профессионалам, пожалуй, надо. Этим же профессионалам писать метаклассы и дескрипторы, пожалуй, тоже не стоит, скорее всего есть более простые способы, но авторам библиотек может быть очень полезно. А зачастую выбирают язык по имеющимся библиотекам, например, в R есть какая-нибудь красивая графикорисовалка и выбирают его, или в python есть pytest/pytorch и выбирают его.
P.S. А вообще можно сразу начинать большой проект на rust, всё остальное лишнее, там и быстрота и более-менее удобство, вот, правда, под одноразовые скриптики и как первый язык для обучения его использовать тяжеловато.
Не понимаю коммьюнити питонистов. То, за что они превозносят язык, ссылаясь на манифест, зачастую проявляется лишь в отдельных фичах языка, причём местами криво (типа явная передача this в методах) и на деле то, что декларируется манифестом во многих других языках реализовано не хуже, если не лучше.
Думаю, основное это
лаконичность: код быстрее пишется и быстрее читается
манифест изрядно ограничивает в возможностях писать спагетти, особенно в сочетании с правильными редактором/линтером. В этом плане можно сравнить с каким-нибудь там паскалем, но у питона код заметно более короткий
де-факто заточенность под ИИ и научные исследования
домохозяечно-низкий порог вхождения. Это, кстати, неплохо сочетается с предыдущим пунктом, потому как учОные - не самые первые таланты в программировании, но штуковину для считать-рисовать им вынь да положь. И тут, - оба-на! - питон
Кстати, this, если не хочется, можно и не передавать. На то существуют classmethod и staticmethod
Вот это-то и не понимаю.
язык преподносится как лаконичный, хотя во многих отношениях он менее лаконичен, чем другие языки.
Про манифест я уже сказал - он что-то декларирует, хотя в самом же дизайне языка противоречит сам себе, а в остальном реализует многое хуже других языков. Черт возьми, уже то что типы не указываются противоречит принципу "явное лучше неявного". А также функции типа len, которые неявно используют магические методы. Как эталон принципа "явное лучше неявного" нам преподносится явный this, хотя это самое неудачная фича языка (this указывается как аргумент при объявлении, но при вызове как таковой не указывается, налицо неконсистентность)
Про заточенность под ИИ вообще не понимаю. Язык под это как раз вроде не затачивался. Напротив, наличие GIL в языке делает его скорее худшим для ИИ и вычислений.
Про низкий порог вхождения ничего не возражу
Кстати, this я таки должен передавать если мне нужны полноценные методы объектов. Тут дело не в моей лени, дело в не очень удачном дизайне языка
Когда-то видел график чёт там объём кода на разных языках, хотел дать ссылочку, но не смог снова найти. Ну так вот, питон где-то в лидерах по компактности. Из "обычных" (которые не лисп, не фортран и не хаскель) переплюнул его, кажется, только перл, который читабельным никак не назовёшь
Уверяю, манифест (дзен) реально рулит. Если применять его к совершенно любому языку, то будет намного лучше. А типы не только можно указывать (аннотации типов), но даже и ведущие собаководы рекомендуют это делать. Насчёт this - ну хз. Не понял, как это он при вызове не указывается. Про магию len тоже не понял
Заточенность под ИИ и науку присутствует, видимо, просто потому что так звёзды сложились. Ошибка выжившего, иначе говоря. Не по хорошу мил, а по милу хорош. Раньше для интерактивщины и прототипирования были R и матлаб, но как-то по-тихому пиплЫ переползли на питон. А GIL тут не мешает. Он, если честно, вообще мало где мешает, чаще помогает. По сути, он защищает от выстрела в ногу. Во внешних вызовах нити не особо-то и нужны, а внутри библиотек (внутри чёрного ящика) они есть и как-то там работают себе. Но там их писали специально обученные люди, которые о выстрелах в ноги знают абсолютно всё и потому умеют уворачиваться
И снова не понял суть претензий к this. Как вообще без ссылки (указателя) на объект иметь доступ к полям объекта?
Черт возьми, уже то что типы не указываются противоречит принципу "явное лучше неявного"
Указываются. До 3.6 (кажется), включая 2.х указывались в комментариях
a = 1
""":type: Optional[int]"""
for val in collection_store: # type: Dict[str, int]
...С введением в систему синтаксиса для type hints, их сразу можно было указывать двумя способами:
from typing import TYPE_CHECKING
from some_mod import DirectType
if TYPE_CHECKING:
from other_mod import ForwardRefType
a: DirectType = DirectType(...)
b: 'ForwardRefType' = ...
Вариант с ForwardReference может сэкономить немножко CPU на импорте, а заодно избавит от циклических импортов с гарантией, если, конечно, прямой доступ к типу не требуется в top-level context of a module.
А также функции типа len, которые неявно используют магические методы
С этим никаких проблем вообще нет. То, как оно работает явно описано в Python Data Model. Наравне с __getstate__, __setstate__ и множеством других "магических методов", через которые язык позволяет модифицировать поведение типов в зависимости от задач при использовании тех или иных built-ins или библиотек из Python Standard Library.
Как эталон принципа "явное лучше неявного" нам преподносится явный this, хотя это самое неудачная фича языка (this указывается как аргумент при объявлении, но при вызове как таковой не указывается, налицо неконсистентность)
С этим тоже абсолютно никаких проблем. Сигнатура метода очень однозначно указывает, что этот аргумент обязателен, что позволяет пользователю языка решать самостоятельно, как вызывать данный конкретный метод:
a: str = "some string"
# variant 1
stripped_string = a.strip()
# variant 2
stripped_string = str.strip(a)Оба этих варианта эквивалентны, разница только в том, что метод инстанса можно вызывать и в статическом контексте, но для этого инстанс явно нужно передать. Более того, это позволяет вызвать метод str.strip() над объектом, который строкой в чистом виде не является, однако, до тех пор, пока данный объект является экземпляром класса, наследующегося от str, данный метод будет работать. Это полезно, например, если частично необходимо "обойти" кастомную логику, навороченную в .strip() наследников класса str. Сравним с Java, например, у которой this вообще при объявлении класса и/или метода нигде не определен, однако используется повсеместно. Что, тоже кривой дизайн? В C++, кстати, та же ситуация.
Указываются. До 3.6 (кажется), включая 2.х указывались в комментариях
Указываются опционально, то есть в большинстве случаев они указаны не будут.
С этим никаких проблем вообще нет. То, как оно работает явно описано в Python Data Model.
Проблем то нет, но это противоречит Дзену Питона - "Special cases aren't special enough to break the rules". Есть набор специальных функций со специальным назначением, которые должны вызывать специально определенный метод класса. Вместо того чтобы просто метод типа length().
С этим тоже абсолютно никаких проблем. Сигнатура метода очень однозначно указывает, что этот аргумент обязателен.
Сигнатура метода не позвляет явно указать, что метод статический. Вместо этого необходимо указывать специальный декоратор. А для метода инстанса self должен идти первым аргументом среди прочих аргументов. То есть this как бы передается явно, но явно не выделяется, что это this. Вместо этого используется соглашения. К слову, то что метод можно вызвать по-разному нарушает "There should be one - and preferably only one - obvious way to do it".
Сравним с Java, например, у которой
thisвообще при объявлении класса и/или метода нигде не определен
У Java нету манифеста где написана куча лабуды в духе "хорошее лучше плохого". У Питона он есть, и я указал что почему он ему соответствует лишь в некоторых частностях, и не всегда на благо.
На месте питона должен оказаться Руби! Человеческий синтаксис, возможность писать dsl. Реально код можно читать как английский. Нормальные класса, наследование, миксины, модули. Вот он - человеческий интерпретируемый язык. Почему его место занял Питон? Может кто нить дать вразумительный ответ?
Успех Питона парадоксален. Сторонники простых объяснений видят причину в ученых и студентах, а также "тех кто после курсов". Но датасатинисты/студенты точно не вывезли бы эту популярность. И ответы на stackoverflow (где язык тоже в топе) понаписали точно не они, а вполне профессиональные программисты (возможно владеющие и др. ЯП). Видимо малословность, срезы, списки/словари и прочий плюшки завлекли и опытных кодеров.
"Питоновость", python-style код - не пустые слова, это всегда кратко и понятно. Кто-то добавит: "... И медленно!", но будет неправ, поскольку почти все медленные места расшиваются использованием быстрых библиотек, написанных на быстрых языках, но (часто) специально для питона (numpy). Либ 400k+ и они все свободны. Легкость кодинга позволила очень много понаписать сайтов (django) и бизнес-логики, а в экономических расчетах Python потеснил даже Excel. Так что электорат языка постоянно и разнообразно вовлечен в широчайший спектр отраслей, профессий, документов, веба и хобби. Ни малейшего признака стагнации, как, скажем, в ... (добавить почти любой язык, клюющий носом вниз в рейтингах, таких - десятки).
Сохраняет лидерство Пиоон в т.ч. и потому что ругают его часто как раз за его сильные и принятые сообществом стороны (классы, наследование, декораторы, отступы вместо скобок). Попытки убедить в том что это плохо или реализовано неправильно - вызывают ~смех~ обратную реакцию роста любви к языку.
Ну не знаю, а почему JavaScript до сих пор занимает такие топовые позиции?
на питоне проще читать чужой код (нет всяких unless и вообще беднее на ключевые слова)?
нет типизирующих префиксов перед именами переменных?
процедурность (тот же self) массовым писателям кода гораздо проще заходит чем ООПшность ?
больше аудитория (а у руби - только японцы и вокруг) ?
Математик, но не программист. Я знаю достаточно нюансов,чтобы утверждать,что использование строгих отступов вместо скобок- это самая глупая мысль...Я как системный программист не могу этого переварить, это вызывает у меня нервный тик.Напишите в блокноте и скомпилируйте.Заплюёте экран,пока табы и пробелы будут по требованию.А ещё больше хардкора-пишите в редакторе на линукс, не IDE
Выше вон товарищ красочно описал, что проблема не в том, что есть style guide, за несоблюдение которого, например, тимлид реджектнет PR, и потому товарищ не видит никаких проблем в следовании style guide (что означает единообразие по отсутпам и символам, их формирующим), а в том, что есть какой-то выскочка, даже не член его команды, который смеет эти отступы требовать. Я так полагаю, у моего визави диагноз тот же.
PS. в редакторе на линукс, я предположу, речь о каком-нибудь vim, как бы я к нему плохо ни относился, всё хорошо с форматированием. Наверное, опять речь о том, что надо обязательно, всенепременно, без всяких условий, сделать не по стандарту. Ну, дело хозяйское, конечно. Могу еще посоветовать вот так писать:
#include <stdio.h>
int main(void) {
char* my_string = "Hello, world!";
my_string[2] = 'y';
my_string[3] = 'H';
printf("%s\n", my_string);
return 0;
}И получить свой любимый нервный тик и заплёванный экран впридачу. Умеючи-то оно и не такие штуки можно написать.
C каких пор больные стали определять диагноз ? :) Это всего лишь мое мнение, не более. Я не делаю замечания команде за форматирование. В команде спецы, у которых свои привычки и взгляды на "скобки". В 90-х многие начинали с бейсика, я же сразу с ассемблера. В 2001 закончил БГУИР. Думаю, кое-кому надо подрасти и потушить сопло, прежде чем высказывать свои личные параноидально-суицидные взгляды инженеру-конструктору с опытом лет так 20 с небольшим :)
Одной из базовых идей нового языка было то, что его код должен быть понятен, как простой английский, чтобы не только писать программы, но и передавать с его помощью идеи между разработчиками.
Как это согласуется с введением таких вещей как walrus?
Есть даже замечательная статья на хабре которая только показывает всю "мощь" его использования https://habr.com/ru/company/otus/blog/555924/
Почему он не мог в каникулы просто телевизор посмотреть?
Что было в голове у Гвидо, когда он создавал Python