Почему во многих Питон-проектах не используют async/await и ООП, как в Java?

Просто потому что by design язык не дает говнокодить кастуя магию, которая будет в итоге понятна только автору

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

почти невозможно

мне кажется, здесь почти не при чём

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

поэтому в кодовую базу проектов на PHP даже лучше не заглядывать

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

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

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

В ассемблере почти нет синтаксического сахара, давайте писать на ассемблере?

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

Мне, тупому, без примеров непонятно.

В ассемблере почти нет синтаксического сахара, давайте писать на ассемблере?

При чём тут «давайте»? Если ты пишешь на ассемблере ты используешь определённые приёмы, т.е. паттерны программирования.

Приведи, пожалуйста, примеры сахара и хаков

Тут в теме уже рассказывают что import foo это синглтон. Очевидно что эти люди не понимают, что такое синглтон и какую задачу решает.

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

Тут в теме уже рассказывают что import foo это синглтон. Очевидно что эти люди не понимают, что такое синглтон и какую задачу решает.

Я так понимаю, что это вопрос определения, что такое «синглтон».

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

И что задачи, которые в C++/Java решает паттерн Singleton, в Python часто проще решить другими методами, что приведёт к более короткому и понятному коду. Возможно, даже, что в каких-то случаях и модуль подойдёт. Надо на конкретный случай смотреть.

А спорить об определениях мне почему-то неинтересно.

А в питоне есть, поэтому питоноджуны это сплошь скприт-кидди, которые научились использовать питоновские декораторы в каком-нибудь flask для объявления роутов, но не в состоянии объяснить как это работает в общем случае, а уж тем более написать декторатор который не вписывается в питоновский сахар.

На собеседовании в любой более-менее серьёзной компании просят написать декоратор. И в этом нет ничего сложного, декораторы использовались в Python ещё до того, как появился сахар @decorator — это просто функция, возвращающая функцию.

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

Да ты офигел и разучился читать, на пальцах я тебе уже всё пояснил. Бате пояснять собрался. Приехали.

Во-первых, контейнеры — это не виртуалки, это просто изолированные процессы. Учи матчасть.

Во-вторых, ты не прав, переключаться между потоками — это всегда дорого, ибо вымывается кеш, а процессы нормальные люди всё равно запускают в пуле. И так как на питоне сейчас в основном пишут сервисы (даже если ML, всё равно будет обвязка в виде сервиса), запуск в контейнере — это идеалочка. То есть мы можем без проблем отмасштабироваться, запустив контейнеров по количеству ядер на тачке/ноде, которые нужно утилизировать. Если же мы не просто данные по сети гоняем, а производим какие-то вычисления, то для этого используется пул процессов, где вычисления и будут происходить, а основной процесс просто будет их ждать, держать коннекты и распределять между ними запросы.

нужна ли тебе возня с потоками в питоне

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

Задел я тебя, похоже, знатно, раз бы так разорится на количество символов в простыне. Извини, такой цели не было.

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

Почему во многих Java-проектах не используют никоуровневный доступ к устройствам и регистрам памяти?

кто не могут осилить даже Пыхтон, идут в PHP

Смешно.

поэтому в кодовую базу проектов на PHP лучше не заглядывать

Информация безуспешно устарела. Старые проекта, типа ВП, да, кромешный процедурно-ОО ад, а новые приличные.

Питон есть, верблюд есть, лиса есть, а а мангуст есть?

Информация безуспешно устарела. Старые проекта, типа ВП, да, кромешный процедурно-ОО ад, а новые приличные.

Почему многие имеют в себе много негатива в отношении языков программирования?

Скриптовые языки редко использую, но вот как-то с использованием JavaScript + PHP своим паучком прошелся по страницам MSDN и на выходе получил тонны *.cpp, *.h и *.idl bindings для работы с API Windows /правда в какой-то момент понял, что API Windows не рационально использовать/.

Да и вэб интерфейс к 1С 7.7 как-то разработал с использованием JavaScript + PHP /был как а-ля вэб интерфейс 1С 8.x/.

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

Ведь не ведут же все разработку системного API …

Надоело НЫТЬЕ многих о том, какое все Г..О …

Почему многие имеют в себе много негатива в отношении языков программирования?

Потому что бездумно хейтить намного проще, чем писать что-то умное.

Аргумент про async зачитан. Но тоже иногда by design это все слишком.

все граммотно оформить по ОО-дизайну с SOLID-принципами

Божемой, зачем? Усатые программисты в брюках и свитерках били книжками по рукам и кричали что это все даст какую-то пользу? Которую они точно так же как попугаи повторяют за кем-то. Да им уже по ночам на кладбище выть полагается.

Усатые

Шутка

«Усатые» созвучно с https://ru.wiktionary.org/wiki/уссаться …

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

Причина 1: потому что все люди так устроены: что-то любят, что-то не любят. Если любят, то считают, потому что правильно устроено. Если не любят, считают, что неправильно устроено.

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

Причина 2: у меня, за мой богатый опыт разработки, появилось ощущение, что есть языки, которые способствуют написанию плохого кода. Я не знаю, как это можно доказать. Просто есть ощущение, что, например, 95% кода на PHP и JavaScript — говнокод. Субъективное, да. Но много раз пытался переубедить себя, и не смог.

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

В чём причина тоже особо не разбирался, и даже уже не особо хочется. Мне проще избегать языков, на которых пишется говнокод, и стремиться работать там, где не используются такие языки, т.к. становиться евангелистом и писать умные книги Patterns + SOLID + Functional OOP DDD Design: How to write perfect code, мне наверное уже поздно.

Усатые программисты в брюках и свитерках

100 программистов - 100 мнений …

Я не знаю, как это можно доказать

Очень просто, если язык даёт много свободы, то, поскольку 95%, будет много говнокода.

серьёзные

из таких «несерьёзных

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

Серьёзность это не размер, хотя связь конечно есть. Можно применить серьёзный подход и к мелким проектам, но там это будет просто нецелесообразно. Вот например - хочешь ты написать гуи калькулятор. Можно заморочиться оптимизацией вывода его интерфейса на экран - сделать прямое взаимодействие с видеокартой, оптимизированные алгоритмы рассчёта графических координат каждой его кнопки, и рассчёта того, на какую кнопку сейас показывает мышка. Ещё можно заморочиться скоростью рассчётов - например скоростью конвертации числа из десятичного представления, которое использует юзер, во внутреннее двоичное и наоборот. Какой-нить хитрый инкрементальный алгоритм нажатия на очередную цифровую кнопку. И т.д. Но нужно ли это тут? Вряд ли. Скорее всего ты возьмёшь готовый тулкит, по-быстрому накидаешь описание интерфейса (в виде данных, а не кода), ну и расчёты буду делаться стандартными общеупотребительными способами. А возможно и тулкит ты не возьмёшь, а сделаешь форму на html+js, и для запуска калькулятора нужен будет браузер.

А теперь представим, что этот калькулятор каким-то образом стал важным узлом сложной системы (хотя конкретно тут это сложно представить, но пусть), и от его производительности много что зависит. Так вот, сувать несерьёзную его реализацию деталькой в серьёзную систему - нельзя, система от этого будет плохо работать. Придётся действительно делать и прямое взаимодействие с видеокартой, и с мышкой/клавиатурой, и везде максимально оптимизированные расчёты. Возможно, под него тебе придётся даже написать специализированную ОС. Да, деталька («микросервис») маленькая, но если ты хочешь её использовать в серьёзной системе - с этой деталькой надо будет заморочиться. И если в качестве самостоятельного несерьёзного проекта её можно было делать хоть на даваскрипте в браузере, то тут будет однозначно компилируемый язык с минимумом оверхедов.

… т.к. становиться евангелистом и писать умные книги Patterns + SOLID + Functional OOP DDD Design: How to write perfect code, мне наверное уже поздно.

Ничего не поздно.

ИМХО нынешние технологии разработки /да и компиляторы/ такие же как и 50 лет назад.

Хоть бы один «Усатый» за 50 лет научил компьютер быть умным.
Ан нет, всю разработку спихнули на программистов, которые учат бестолковые компьютера выполнять свой код.

По существу живем в доисторические времена, когда по земле еще бегали МАМОНТЫ …

У меня есть интуитивное ощущение, что отчасти зависит от порога входа.

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

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

Чем ближе язык к первому варианту, тем больше будет говнокода. Хотя, по идее, Python тоже ближе к первому варианту, но, видимо, не настолько же, насколько JavaScript, например.

это просто функция, возвращающая функцию

Да, и внимание, это не декоратор в обычном понимании везде за пределами питона.

Я всё ещё не могу понять

Ну ок.

Да, и внимание, это не декоратор в обычном понимании везде за пределами питона.

Ну, то есть, мы опять вернулись к вопросам терминологии, ok. Это, наверное, очень важно.

Ну ок.

Ну, ok.

Серьёзность — это про архитектуру. А в твоём примере калькулятор мы перепишем на Go, плюсах или возьмём Cython. Микросервисы отвязывают нас от ЯП.

У меня есть интуитивное ощущение, что отчасти зависит от порога входа.

А порог входа зависит от того, что язык позволяет делать.

Python тоже ближе к первому варианту, но, видимо, не настолько же,

Питон ещё ближе. Просто у ЖС есть одна особенность: на нём думают, что программируют, дизайнеры.

В языке с динамикой ты синглтон точно так же можешь переопределить

Да ладно. В пыхе я могу сделать синглтон, вот прям 1:1 как в жабе. В js конечно тоже костыли, но там хотя бы есть константы. Константа + модуль это уже почти как надо.

О, проглядел. Потоки в питоне не зелёные. Ты путаешь понятия.

Зелёные потоки — это greenlet и Stackless Python. В CPython потоки системные.

калькулятор мы перепишем

В том и дело. Лучше сразу писать на подходящем языке, если планируешь что-то соответствующее. И питон там получается не нужен.

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

По существу живем в доисторические времена, когда по земле еще бегали МАМОНТЫ …

МАМОНТЫ, это все без исключения языки программирования …

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

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

emorozov

Так или иначе, питон это временное решение (по сути прототип, даже если впрямую и не называть им). Нацелено на скорость разработки, а не на качество результата. Это и ответ автору этой темы, почему в питон софте все плюют на «как потом развивать код» и пишут лапшу. Но некоторые (может и многие) продукты не осиливают дорасти до прод-состояния (компания-разработчик увязает в болоте), так и остаются питон-лапшой, которую выдают за готовый продукт за неимением лучшего.

количество говнокода уже зависит от языка непосредственно

Щас тебе emorozov расскажет, что говнокод это вопрос терминологии.

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

И от энтропии зависит, только речь сейчас про вакуум.

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

Большинство разработчиков, как бы вы не удивились, далеко не старшие.

В результате большинство кода, каким бы выразительным ЯП не был, стремится к дну.

Во-первых, ты не прав абсолютно, вот тебе даже пруф: https://insights.stackoverflow.com/survey/2021#section-experience-years-coding

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

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

Щас тебе emorozov расскажет, что говнокод это вопрос терминологии.

Чувак, ты меня попытался подловить на том, что когда говорят «декоратор» в Python, обычно имеют в виду совсем не то, что называют словом «декоратор» в других языках.

Ну молодец, чё. Возьми с полки пирожок.

Декоратор в питоне — это ровно то, что подразумевалось в GoF.

В целом конечно архитектура динамических объектов должна быть хорошая.

Вчера настрочил много БУКВ, но не стал публиковать пост потому, что как-бы смахивало на хвастовство.

Сегодня вот подумал, а почему хвастовство?
Как бы попытаюсь сегодняшним постом на конкретном примере, продемонстрировать, что динамические объекты могут и не ТУПИТЬ.

Ниже маленькая иллюстрация.

На выполнение алгоритмов требуется где-то секунда.

Парсинг метаданных об объектах + создание их + к примеру парсинг метаданных конфигурации /15000 строк без комментариев/ + парсинг 730 диалоговых форм + парсинг 200 mxl + системного GUI …

При парсинге все поля приводятся к их нативному представлению и помещаются в динамические объекты …, …, …

Анализировал архитектуру объектов Python.
ИМХО

Бородино

Это «временное решение» на постоянку используют самые крупные корпорации в своих ключевых и самых прибыльных проектах. То, что ты говоришь, попросту расходится с реальностью. Поменьше фантазируй, набирайся опыта, корректируй свои позиции с поступлением новой информации.

Во-первых, ты не прав абсолютно, вот тебе даже пруф: https://insights.stackoverflow.com/survey/2021#section-experience-years-coding

Круто, у меня информацию из ДОУ, там как раз большинство — до 5 лет.

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

Так-то да, но когда прилетает $str[mb_strlen($str) - 1] понимаешь, что джун джуну рознь.

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

Неужто у модератора.

$str[mb_strlen($str) - 1]

Вах, красивое.

Декоратор в питоне — это ровно то, что подразумевалось в GoF.

Ну так если не НавернутьСверхуКучуКлассовВКамелКейсе, то нещитово =)

Круто, у меня информацию из ДОУ, там как раз большинство — до 5 лет

Детское Оздоровительное Учреждение?

Просто же всё, старые разрабы не вымирают так быстро, чтобы нубы внезапно стали большинством.

Неужто у модератора

🤭 (только не называй)

Детское Оздоровительное Учреждение?

https://dou.ua/lenta/articles/language-rating-jan-2021/

Поясните для тех, кто не умеет в ПХП.

Наверняка, можно просто $str[-1]? Если так, то это же вовсе не жесть. Меня в нубском коде больше всего выводит непонимание DRY. А не знать все тонкости языка для джуна простительно.

fernandos

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

Бородино

Питона звали Петя и он не виноват в том, что пока все похоже на лозунг большевиков

Дураки всего мира - СОЕДИНЯЙТЕСЬ!

Индексация строк побайтовая.

Чел берёт количество utf8-последовательностей строки, вычитает 1 и индексирует строку этим числом, что бессмыслица.

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

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

Декоратор в питоне — это ровно то, что подразумевалось в GoF.

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

Понятнько, я думал там строки юникодные.