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

Сколько пробелов должно быть у вставляемого кода?

В приведённом примере IDE сама не сможет корректно расставить отступы, поэтому она должна сделать так, чтобы пользователь обратил внимание (а ещё лучше, чтобы код был некорректен). Из предложенных вариантов лучше всего подходит:

4. ноль

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

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

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

ноль

А дальше руками?

У меня такие ситуации не вызывали проблем на практике

Ну конечно, наши руки не для скуки.

Предполагаю, что люди, утверждающие, что «разработка большого проекта на Питоне - это боль» на самом деле в никаких таких проектах не участвовали

Полагаю, что утверждающие обратное на самом деле не профессионалы. Например для профика велосипедиста любой грамм веса вела имеет значение. А для не профика «на практике это проблем не вызывает». И так в любой сфере деятельности. Те кто говорят что «подвигать руками» это не проблема, просто не имели практики нужного уровня. Можно конечно 15 лет писать скриптуху для физических расчётов, или неспешно пилить госбюджет в НИИ. Вопросов нет тогда, потому что это не профессиональное коммерческое программирование.

По моей оценке на вот эти пассы руками в питоне уходит 5-15% времени разработки. Это в специализированных средах. В обычном блокноте это может отнимать до 50% времени. Но даже эти 5% которые отъедаются у каждого разработчика в большой конторе складываются в такое количество человекочасов, что эффективное количество разработчиков может быть на несколько человек меньше номинального. Причём чем выше классом разработчик, тем больше сказываются эти накладные расходы. Для джуна, который в принципе пишет код с 10 попытки и имеет кашу в голове, эти движения могут сказываться не так заметно, т.к. есть куча других накладных расходов. У хороших программистов накладные расходы на ручное форматирование становятся очень заметны.

А дальше руками?

Дальше руками.

По моей оценке на вот эти пассы руками в питоне уходит 5-15% времени разработки.

Не совсем понятно, на чём это основывается. Обычно вставляется либо одна строка без отступов, либо целиком функция. В обоих случаях у IDE и программиста проблем нет и ничего не надо корректировать. У меня больше вызывает раздражение, когда в языках «со скобками» IDE начинает сама добавлять или убирать скобку там, где не просят.

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

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

Соответственно, на Питоне команда может работать только при высокой культуре разработки у всех участников. А, например, при разработке на Java или C# это не обязательно.

Дальше руками

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

Мастерское переобувание в воздухе за один ответ.

очень жаль вашу шарагу и удивительно, что вы называете ее институтом

untitl3d ★ (29.06.23 23:39:09 MSK) плоскозём, никакого Гагарина не было

проблемой может быть не отступы, а динамическая типизация

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

Отступы.
Однострочные блямбгды.

В этом случае проблемы могут возникнуть даже в плюсах

Ну скобочку поставят, а то что оно нечитаемо без табуляции — так это не привыкать! Можно вообще без переносов строк писать в одну линию!

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

поэтому я в плюсах иногда комментирую закрывающие скобки;-(

Так нормальная же практика для конских функций ._.

IndentationError: unexpected indent

Если на пайтоне вы сталкиваетесь с такими «ошибками», то значит на языках с фигурными скобками вы пишите write-only портянку. Отступы строго необходимы для обозначения вложенности читаемого кода. Пайтон всего лишь ввёл это правило оформления в качестве элемента синтаксиса, и заодно сильно разгрузил текст от излишней пунктуации.

Мастерское переобувание в воздухе за один ответ.

Выдернул цитаты из контекста и делает выводы. В одном случае говорится о вставке абзаца, в другом - строки или функции. Есть же разница.

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

Просто у Россуменьбека на этот счёт свои загоны вот и всё.

Это вообще никакая не проблема. Потому что есть линтеры и тесты.

При чём здесь линтеры. Я говорю о навигации по коду. Как тут поможет линтер или тест? Как линтер положит в Вашу голову понимание чужого кода?

Так же динамическая типизация не всегда справляется с автоматическим дополнением. Хотя современные IDE иногда и здесь удивляют в хорошем смысле.

А вот выравнивание принципиально неоднозначно при рефакторинге. Его невозможно автоматически проверить.

Предположим, у вас функции на 500 строк и по 10 уровней вложенности. Тогда действительно могут быть проблемы. Но это говорит о низкой культуре программирования. Зачем Вам в данном случае рефакторинг?

…по накурке…чмырить школьников…

Ну что за детский сад. Вы же можете адекватно вести дискуссию. Или я Вас с кем-то путаю.

Дурацкий аргумент. С переформатированием кода-со-скобочками под любую красоту прекрасно справляются astyle и аналоги.

Что пробелы, что скобочки – один фиг. Блоки кода сами себя не выделят.

Можно вообще без переносов строк писать в одну линию!

У меня один одногруппник в студенчестве так на сях и кодил. Без лишних пробелов. Когда место заканчивалось - строчку переводил.

Вы же можете адекватно вести дискуссию.

На эту больную тему очевидно не может. Он тут уже два раза порвался.

За что не любят Python? (комментарий)

Я говорю о навигации по коду. Как тут поможет линтер или тест

В PHP, например, с этим нет никаких проблем при использовании аннотаций.

это говорит о низкой культуре программирования

Бизнесу наплевать на культуру, бизнесу нужно ехать. Код неизбежно эволюционирует от красивой идеи к говонокоду на грани работоспособности. Но именно на грани, т.е. минимально достаточному, но не хуже. Так устроен мир.

Зачем Вам в данном случае рефакторинг

Потому что это реальные задачи, в которых даже сама постановка задачи может меняться, не говоря уж о подходах. Это не школьные лабы, которые ты один раз написал по методичке, сдал и забыл. Почему я должен повторять по 100 раз одно и тоже? Почитай тему, хотя бы. Ведь это же очевидно любому, кто работал в бизнес проектах, а не просто в НИИ штаны протирал.

Вы же можете адекватно вести дискуссию

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

В PHP, например, с этим нет никаких проблем при использовании аннотаций.

Могу только на веру принять то, что линтер в PHP помогает в навигации с помощью аннотаций. В любом случае, тут языки со статической типизацией имеют преимущество.

Бизнесу наплевать на культуру, бизнесу нужно ехать. Код неизбежно эволюционирует от красивой идеи к говонокоду на грани работоспособности.

Так я же сказал, что код на Java или C# лучше подходит в данном случае, чем Python. В чём противоречие?

рефакторинг

Я не спрашиваю зачем вообще нужен рефакторинг. Я говорю, что программист с функциями на 500 строк кода и 10 уровнями вложенности явно не использует рефакторинг. Он ему не нужен.

С чем конкретно ты не согласен в том моём утверждении про «чмырить школьников», если без лирики?

У меня было замечание к форме изложения. Если говорить по смыслу, то тогда надо приводить ссылку о том, что Гвидо был наркоманом, обижающим школьников. У меня таких данных нет.

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

Три персонажа, у которых стул плавится под седалищем от отступов, точно не разрабатывали. Но я уже даже не хочу комментировать, ибо там хоть кол на голове теши. Ещё и придумали какие-то метрики, типа того, что 10-15% времени тратится на отступы. Фейспалм. Но ладно, тут только галоперидол может помочь.

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

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

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

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

Ещё одна проблема: запутанная система импортов. Надо понимать, что Python начинался очень давно, и система импортов и пакаджей навешивалась сверху, путем подстановки костыликов под различные юзкейсы (например, namespace packages). Из-за этого, бывает, что приходится поломать голову, как структурировать свой пакет или библиотеку, или почему что-то не импортируется. Но это скорее джуно-миддловская проблема, т.к. всё формализовано, и если раз и навсегда запомнить правила импортирования, то сюрпризы быстро разрешаются.

Третья большая боль, на мой взгляд: разброд и шатание в системах организации виртуальных окружений и проблема с подтягиванием зависимостей. Есть несколько различных утилит для создания окружений и установки зависимостей, ни одна из них не идеальна, хотя poetry, на мой взгляд, близка к идеалу.

Четвёртая боль: Python медленный. Это имеет значение гораздо реже, чем считают многие, но иногда всё-таки имеет значение.

программист с функциями на 500 строк кода и 10 уровнями вложенности явно не использует рефакторинг. Он ему не нужен.

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

Сделать декомпозицию не всегда возможно - контекст может быть толстый, производительность важна.

Если контекст толстый, то применяют ООП. То есть все переменные становятся полями класса, а в методы класса выносят тела циклов и условий (if, else). Понятно, что это производительности не прибавит. Но в данном случае уже удобнее будет профилировку делать, а затем оптимизировать самую жрущую функцию. Можно для таких функций даже сишную библиотечку написать и подключить через ctypes.

Можно для таких функций даже сишную библиотечку написать и подключить через ctypes.

Через ctypes медленно будет работать, т.к. каждый раз надо типы преобразовывать из Python обёрток в C-шный ABI, а затем обратно. Это съедает выигрыш в производительности.

Выгоднее использовать Cython или написать полноценное расширение на C.

Разумеется я говоря про плюсовый код (раз уж производительность важна).

На питоне у меня функций на 500 строк вроде нет:-)

Ну т.е. некоторым без препроцессора никак. В таком случае, пайтоний синтаксис не проблема, т.к. исходник можно писать как угодно, хоть с begin/end.

пайтоний синтаксис не проблема, т.к. исходник можно писать как угодно, хоть с begin/end.

Ну, как? Теперь слышите тонкую фекальную нотку в «Отступы строго необходимы»? ;)

Не слышите? А давайте я вам помогу…
Представьте, что пайтон «ввёл в качестве элемента синтаксиса» такое правило как «строки должны умещаться до 80-ого столбца».
И чтобы было веселее, всё что дальше просто игнорируется.

Я люблю Питон как язык, но не люблю его инфраструктуру.

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

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

Странное заявление, большинство сайтов на WordPress, а о CMS на Python я вообще не слышал, в какой же области он его убил?

Давайте лучше я Вам помогу, мечтать так мечтать бредить так бредить! С завтрашнего дня:

1. у явы все переменные должны начинаться на a
2. в PHP запрещены заглавные буквы
3. в перле запрещены числа, все числительные вводятся словами

Выгоднее использовать Cython

Я пробовал. Получилось многократно медленнее, чем ctypes или CFFI.

медленный, зоопарк вариантов как его развернуть venv/conda и т.д. и т.п., между версиями иногда ломается, а остальное вкусовщина

Можно вашу команду знать? Чтоб я случайно к вам не пришел если буду работу искать? А то у вас не только интерн анскильный, а ещё и все остальные, раз не смогли ему помочь без ресета винды анаконду удалить. Там же 5 минут дело.

Вам наверное надо на деньгах объяснять.
У пыхпыха где-то в стайлгайде сказано «не рекомендуется использовать заглавные буквы»? Может быть жаба рекомендует начинать переменные на «а»? (По перлу сейчас видимо только одна рекомендация может быть: если надо это трогать, то начните с переписывания на другой язык.)

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

У пыхпыха где-то в стайлгайде сказано «не рекомендуется использовать заглавные буквы»?

А Вы не путаете часом питоновский стайлгайд (который является РЕКОМЕНДАЦИЕЙ и совсем не одинок со своим ограничением в 80 символов) и вот это Ваше «всё что дальше просто игнорируется»?

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

Чужой код на незнакомом языке раздражает только тех, кто полез в чужой код на незнакомом языке.

Пофиксил, не благодарите.

приписывать чудесные свойства стилемагии отступов тоже не стОит.

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

Разумеется, я говорю про плюсовый код

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

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

Я в курсе;-) На нашей полянке такие функции это неизбежное зло. Их мало, но они таки есть…

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

IDE не проверяет, действительно ли закрывающая скобка с комментарием switch ( TypeField ) { соответствует блоку switch

Потому что вменяемый программист СРАЗУ пишет комментарий к закрывающей скобке: } //конец бла-бла-бла. Ещё до того, как хоть что-то написал внутри скобок.

Вряд ли вменяемый программист может быть невменяемым косплеером физика вроде Вас @

Потому что вменяемый программист СРАЗУ пишет комментарий к закрывающей скобке: } //конец бла-бла-бла. Ещё до того, как хоть что-то написал внутри скобок.

Когда код подвергается многократному рефакторингу и доработкам, то возникают другие обстоятельства по сравнению с написанием оригинального кода первый раз.

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

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

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

Т.е. пишется тот же if, прогер набирает { и редактор сразу печатает {|}, т.е. и курсор ввода текста уже между скобок. А после набора жмакаешь кнопку «сделать красиво» и редактор тебе автоматом ПРАВИЛЬНО расставит отступы в соответствии с логикой, заданной явными операторными скобками.

Т.е. пишется тот же if, прогер набирает { и редактор сразу печатает {|}, т.е. и курсор ввода текста уже между скобок. А после набора жмакаешь кнопку «сделать красиво» и редактор тебе автоматом ПРАВИЛЬНО расставит отступы в соответствии с логикой, заданной явными операторными скобками.

Во время доработки кода и добавления новых фич нередко приходится оборачивать новыми блоками УЖЕ СУЩЕСТВУЮЩИЙ код.

Бессмысленно, когда IDE добавляет пустой блок { }.

C true рефакторингом вероятно получше, когда операции рефакторинга происходят сразу над выбранными участками кода?

А после набора жмакаешь кнопку «сделать красиво» и редактор тебе автоматом ПРАВИЛЬНО расставит отступы в соответствии с логикой, заданной явными операторными скобками.

Ты не поверишь: во всех адекватных редакторов от vim до PyCharm код тоже можно ПРАВИЛЬНО и красиво отформатировать нажатием одной кнопки.

Или в пре-коммит хуке при помощи black и других утилит.

И всё работает!

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

Для разработчика очевидно упоротый синтаксис.

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

Название плохое?

тред не читай @ сразу отвечай

Это была, кстати, miniconda (привет, говнопитон, еще раз). Он ее удалял/переставлял раз 500 и даже искал поиском и ручками все, что как либо относится к питону и удалял из системы. Ничего не помогло, кроме сноса венды.

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

код тоже можно ПРАВИЛЬНО и красиво отформатировать нажатием одной кнопки.

Вы имеете ввиду питоновский? Ну, редактор может привести отступы к единообразному виду, если отступы УЖЕ заданы. Но тут вопрос не в красоте, а в правильности кода.

Вот тут мне указывали, что может потребоваться уже имеющийся блок кода «завернуть» в операторные скобки. Для ЯП с явными о/скобками в редакторе кода это просто и очевидно: сворачиваем блок, отрывающуюся скобку ставим в строке перед, закрывающуюся – в строке после. Редактор кода далее красиво расставит отступы сам.

Как это делается с кодом на Питоне?

В Python отступы заданы всегда. Они не могут быть не заданы. Откуда у нас возьмётся блок кода на Python без отступов? Неоткуда ему взяться.

Если мы копируем пример со StackOverflow - у нас копируемый код уже содержит отступы. Если мы копируем кусок кода из своей же кодовой базы - он уже содержит отступы.

Если мы хотим сделать копируемый блок частью другого блока, отступы у нас не совпадают, а редактор вдруг не смог понять, что мы хотим, и не выровнял блок автоматически (хотя такое бывает редко), то выделяем текст, и нажимаем </> в vim или Tab/Shift-Tab в другом редакторе.

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

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

... анального жжения у особо упоротых.

Пост не к emorozov.

«Тупоконечники» и «остроконечники».

Классика жанра IT!