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

$str[mb_strlen($str) - 1]

Я только что нашел того, кто переплюнул этот говнокод.

    # jam is weird, likes to error
    jam || true

Ахаахааа, это что-то из авторской логики.

Там еще есть прекрасное.

CXXFLAGS выставляется, но не экспортируется. Дочерние процессы видимо телепатически должны угадать её значение.

Это ещё можно худо-бедно списать на забывчивость и отсутствие тестирования, но чтоб jam || true, это прямо очень грустно.

Из интересного ещё: когда-то слышал про вложенный оператор die, но лично никогда не встречал.

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

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

Потому что ООП и asyncio - инструменты которые нужны не всегда. /thread

Другое дело что часто вместо asyncio используют питонью форкательную «многопоточность». К этому подходу действительно возникает много вопросов.

Все-таки, Python не является Haskell, OCaml или каким-нибудь диалектом LISP.

… при чём тут диалекты LISP? Забыл название преимущественно функционального Scheme?

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

Потому что async/await — тормозное явление, которое подходит для небольшого класса относительно специфичных задач.

А ООП в том виде в котором его в девяностые-нулевые придумали-реализовали джава-программисты и им сочувствующие — откровенная жесть. Сервисы, менеджеры, провайдеры, модели, сторы, вью, контроллеры, фасады, визиторы и прочие представители зоопарка паттернов в наличии, а чтоб понять что код реально делает, приходится мозолить кнопку go to definition и задумчиво тыкать в дебаггер.

Потому что async/await — тормозное явление, которое подходит для небольшого класса относительно специфичных задач.

async/await это самый производительный подход к многозадачности. Он нынче используется практически везде.

Сервисы, менеджеры, провайдеры, модели, сторы, вью, контроллеры, фасады, визиторы и прочие представители зоопарка паттернов в наличии, а чтоб понять что код реально делает, приходится мозолить кнопку go to definition и задумчиво тыкать в дебаггер.

Такое ощущение, что ты не осилил технологии 90-х и обиделся на весь мир.

async/await это самый производительный подход к многозадачности. Он нынче используется практически везде.

У async/await есть небольшой, но оверхед. На внутренности евентлупа, на все эти коллбеки-промисы-футуры и прочие абстракции над вызовами функций и передачи в них значений, на то, чтобы договариваться с ядром об этом самом асинхронном IO. Если мы делаем http-запрос куда-то далеко, то имеет смысл. Если обращаемся к базе с простым запросом аля select foo from bar where id=11, то тут уже есть варианты. Если запрос уходит на другую физическую машину, то наверное ещё есть смысл в async/await. Если дело происходит в пределах локалхоста по юникссокету или вообще через shared memory, то тут уже лучше бенчмаркнуть.

Такое ощущение, что ты не осилил технологии 90-х и обиделся на весь мир.

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

У async/await есть небольшой, но оверхед

Давай сравнивать разные подходы.

Если мы используем потоки ОС, то в оверхед уходят:

1. Стеки потоков. Условно 8 МБ виртуальной памяти, используемая память с гранулярностью в условные 4 КБ. Т.е. если мой поток реально кушает 20 байтов на стеке и ему этого хватает, то всё равно ОС ему выделит 4 КБ. Также в оверхед уходит сохранение/восстановление кучи регистров и переключение между режимом пользователя и ядра. Это считается самым большим оверхедом.

2. Зелёные потоки, на примере Го. Со стеком тут всё примерно так же. Также глубокие стеки вызывают перерасход памяти, даже если они не используются. К примеру у нас энтерпрайз, и от начала потока до нашего реального метода проходит 500 вызовов всяких фреймворков. И в каждом потоке эти 500 вызовов будут дубликатами висеть и от этого никак не избавиться.

3. async/await. Тут перерасхода никакого по сути. Идёт замыкание исключительно с нужными данными, пара указателей. Задача может занимать считанные десятки байтов, вне зависимости от того, сколько вызовов было потрачено, пока к ней дошло управление.

4. Ручная state-машина. Ну по сути это самый оптимальный вариант. Причём async/await в идеале в неё и превращается.

Можно обвинять async/await в неудобной модели для программиста и я первый тут поддержу. Читать запутанный async/await-код может быть сложно. Научиться async/await ещё сложней. Лично я за зелёные потоки, как оптимальная середина - и для программиста всё просто как два рубля, и по производительности приемлемо. Но всё равно я считаю, что async/await (или на коллбеках алгоритмы) самые оптимальные по производительности. Хоть на удалённый сервер, хоть на локалхост, какая разница, всё равно тебе нужно организовывать управление соединениями.

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

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

Что там по памяти — не особо принципиально. 512гб памяти не так уж и дорого стоят, если их покупать планками для сервера, а не арендовать у амазона в виртуалках. А вот миллисекунды если считать, то тут async/await не всегда в выигрыше, если через него делается что-то глупое, вроде доступа к локальным мелким файлам.

Gentooshnik ★★★★ (23.11.21 10:05:11)

… при чём тут диалекты LISP? Забыл название преимущественно функционального Scheme?

Хорошо, поясню. Я написал про это, т.к.:

Некоторые питонисты сильно увлекаются ф-циональщиной настолько, что пытаются в Питоне чуть ли не все оформить в функциональном стиле, однако Python != true functional lang, как мной же упомянутой Haskell (помимо LISPa, я ряд языков привел). По большой степени дело не в Лиспе или Хаскелле… А больше про новые возможности Питона последних версий.

Короче говоря, суть моего поста была в том кратце:

• почему многие до сих пор пытаются писать глобальные def()’ы и заниматься форканием?

Когда есть ряд других возможностей. Не нравится ООП? Хорошо, можно в functional стиле писать, но только соблюдая иммутабельность, pure functions и прочее, что есть в мире функциональщины (поэтому и привел Haskell).

Или, писать-таки в ООП стиле. И не пытаться форкать, а начать юзать механизмы для синхронизации с asyncio.

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

Всё. Ну и, народ стал разубеждать, что мол пишем и что все норм. А часть людей стала писать:

• зачем ООП?
• что пристал к форкам, мол и так все норм.

Ну, собственно и всё. Плюс, добавлю от себя, что не совсем понимаю, что так GoF обсирают. По мне так, есть весьма элегантные паттерны/решения. Ну видимо, Java поразила мозг. Ок, соглашусь поразила.

любителя пожамкать питона

С питоном, походу у него все плохо. Помню договаривались на свиданку в Ебурге. Я собиралась как нормальная попить чаю и поебаца, а он такой «Лиза, пойдем в музей». Спасибо, что зоопарка там нет.

Djanik (23.11.21 14:45:38)

Я собиралась как нормальная попить чаю и поебаца, а он такой «Лиза, пойдем в музей». Спасибо, что зоопарка там нет.

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

Если обращаемся к базе с простым запросом, то тут уже есть варианты.

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

надо десять раз и к трём разным базам

Да, async/await — подорожник для прикладывания к кривой архитектуре.

к кривой архитектуре.

И в чём конкретно заключается «архитектурная кривизна» одновременной параллельной обработки задач? В том, что результат будет в N раз быстрее, чем при последовательной?

в питоне невозможна функциональщина. в функциональном стиле можно писать на js

Тем что в задачах вида «CRUD-обыкновенный» почему-то вообще возникает необходимость обработки нескольких задач в рамках одного запроса. Если таковая задача есть, то async/await не самый плохой метод её решения. Писал всякие пауки-скрейпилки на питоновском asyncio ещё с тех времён как await называли yield from. Но желания тащить эту парадигму без разбора во все вебфреймворки как единственно верную я не разделяю.

задачах вида «CRUD-обыкновенный» почему-то вообще возникает необходимость обработки нескольких задач в рамках одного запроса.

Потому что в 2К21 в профессиональной разработке «CRUD-обыкновенный» существует только в контексте обработки «пользовательского» запроса из логики сильно больше единственного селекта из таблички.

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

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

ООП в Python есть. Оно не такое самобытное как было в JS с его прототипным наследованием, но оно есть. И твое словоблудие мол все тут говорят, что ООП не нужно - это ЛПП. Питонистам не нужно абсолютное большинство Java-паттернов (в Питоне они, внезапно, есть свои) и никому в сраку не вперлось писать в Java-стиле, так как этот стиль порожден бедностью и невыразительностью языка Java. Тебе никто не запретит писать как ты привык, но других ты уже не заставишь. Если хочешь писать на Java, то бери… PHP и пиши… или Angular с TypeScript… Но реально тебе это не нужно, потому как вакансий на Java море

про приватные проекты компаний

Компании и спрашивайте.

tz4678 ★★ (23.11.21 17:02:29)

ООП в Python есть.

Понятно, что есть. Даже в треде соль не об этом, соль о другом. Почему многие Питонисты вообще не соблюдают ни каких паттернов, а фигачат глобальные def() и форкаются. Повторяю уже 4ый или 5ый раз.

tz4678 ★★ (23.11.21 17:02:29)

И твое словоблудие мол все тут говорят, что ООП не нужно - это ЛПП.

Ну так, не моё. Можно во всем треде покопаться и поискать явно фразы у других участников «ООП не вперлось, не нужно на Питоне». При этом, не я это сказал, хочу подчеркнуть. Получается, что по логике - что не моё уже словоблудие? :)

tz4678 ★★ (23.11.21 17:02:29)

так как этот стиль порожден бедностью и невыразительностью языка Java

Прошу в студию конкретные «бедные» и «невыразительные» места у Java, иначе это словоблудие уже с твоей стороны.

tz4678 ★★ (23.11.21 17:02:29)

PHP и пиши… или Angular с TypeScript…

1. Боже упаси от ПХП
2. Казалось бы причем тут Ангуляр? NodeJS может хотел сказать? Сервер-сайд пишут без Ангуляра, это MVVM-фреймворк для frontend UI, а сервер-сайд пишут на NodeJS/TS - да. Есть знакомые у меня, но я предпочту GraalVM/Java лучше или тот же Питон с его фреймворками и либами для сервер-сайда.

P.S. не, давай разбирать тему ООП. К примеру, ты тут показывал «якобы синглтон», я соглашусь с другим человеком, что это не фига не синглтон. Причем интересно, как ты вывернешься, если я попрошу реализовать тебя синглтон с «ленивой инициализацией» именно в контексте твоего примера в данном треде… У меня что-то складывается ощущение, что ты не открывал книжечку по Design Patterns, а судишь по статьям из Википедии и сугубо через «свое ИМХО».

Почему многие Питонисты вообще не соблюдают ни каких паттернов, а фигачат глобальные def() Потому что не надо писать self на каждый чих, БУДУМ ТССС

Понятно, что есть. Даже в треде соль не об этом, соль о другом. Почему многие Питонисты вообще не соблюдают ни каких паттернов, а фигачат глобальные def() и форкаются. Повторяю уже 4ый или 5ый раз.

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

Можно, пожалуйста, статистику: кто эти многие пользователи, какие именно паттерны не используются.

И/или конкретные примеры.

К примеру, ты тут показывал «якобы синглтон», я соглашусь с другим человеком, что это не фига не синглтон.

Господи, да нафига к этому, самому идиотскому из всех паттернов, цепляться? Синглтон — это почти всегда дурно пахнущий код, антипаттерн. Чаще всего им джуны, начитавшиеся «умных» книжек, увлекаются, пихая во все места совершенно не по делу.

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

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

Приведи пример паттерна, который ты хочешь видеть в питоне.

emorozov (23.11.21 18:02:50)

Какие паттерны? Про паттерны уже перетёрто в этом только треде 10 раз: многие паттерны в Python не нужны

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

emorozov (23.11.21 18:02:50)

т.к. они разрабатывались для других языков и условий.

Вы все голдите про Java, но самое смешное, что в книге Design Patterns фигурирует Smalltalk, а не Java. Джеймс Коплин про С++ дописал насчет Design Patterns. Вот и, спрашивается про какие языки вы голдите все? Java не употребляется. А что написал дядя Фаулер - так это, не относится к книге Design Patterns, вообще-то. У него своя лит-ра есть…

emorozov (23.11.21 18:02:50)

Можно, пожалуйста, статистику: кто эти многие пользователи, какие именно паттерны не используются.

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

emorozov (23.11.21 18:02:50)

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

Цепанулись, т.к.:

1. он самый простой
2. уже возникли проблемы на самом простом, то что в треде показывали напротив Синглтона - это параша, а не синглтон
3. когда начинают просить по-сложнее, товарищ с БДСМ-котом уже начинает сливаться, что намекает
4. хорошо, можем переключиться на другой паттерн… давайте «абстрактную фабрику» разберем
5. где опубликована статья/устав, что Синглтон - это самый идиотский паттерн? хочу ознакомиться
6. если он такой идиотский, фигли параша уже с ним началась? (повтор)

emorozov (23.11.21 18:02:50)

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

Ну «да»… А потом, такие как вы начинаете адептов Domain-Driven Design по схожей манере преследовать, «а фигли это сложната нужна?», причем с вашего лаегря видно, что вы даже не вдавались в детали имплементации стратегических или тактических паттернов. Ну а, фигли? 100500 def()’ов нафигарим и типа «работает». Про это, как раз и трэд… Фигли на вас GoF/DDD действуют, как на вампира - чеснок.

tz4678 ★★ (23.11.21 18:09:11)

синглтон вообще антипаттерн. в твоей джаве в файле можно объявить только один класс.

• https://www.quora.com/Can-we-keep-more-than-one-class-in-a-single-java-file

• https://www.delftstack.com/howto/java/multiple-classes-in-a-single-file-java/

«Да-да». Из IDEA пруфы буду слать совсем в крайнем случае.

tz4678 ★★ (23.11.21 18:09:11)

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

Я не вижу смысла общаться с человеком, который не значет что такое синглтон и фигачит громкими словами, не анализируя информацию по Java. Уже ранее я тебе в данном треде с пруфами слал насчет String-типа и Char-типа.

Почему многие Питонисты вообще не соблюдают ни каких паттернов, а фигачат глобальные def()

Потому что не надо писать self на каждый чих, БУДУМ ТССС

А ты хорош.

абстрактную фабрику

Просто функция (классы, в которых ровно 1 юзабельный метод — антипаттерн, см. Stop writting classes). Добавить аннотации типов по вкусу.

Это не опровергает высказывание полностью. Синглтон нужен как костыль, потому что в джаве нельзя ничего иМпортировать кроме класса. Я не знаю Java и знать не хочу.

товарищ с БДСМ-котом уже начинает сливаться, что намекает

на то что ты меня затроллил

Потому что нормальные программисты, если им нужно ООП

зачем нормальным программистам ООП?

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

кучу времени приходится тратить на то, чтобы хоть как-то худо бедно осилить C++ и ООП, а жизнь одна….

Софт не должен быть быстрый, он должен быть good enough по скорости (ну и поддерживаемый, но это другой вопрос)

Спасибо, что зоопарка там нет

Где там? В Екб есть зоопарк. А ты в Екб что-ли ошиваешься?

исключительно в залы с обезьянами

Слабенько. Нужно идти в вольер со слонихой. Ну или к змеям.

Норм. программисты выбирают подходящее средство для решение задачи.

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

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

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

для них бидон лишь вспомогательное средство и вертели они на пне ООП в целом и шаблоны проектирования в частности

именно, просто люди не хотят усложнять себе жизнь без необходимости

и которым довольно тяжело даётся концепция классов и объектов

да нет в ООП никакой китайской грамоты, просто если можно прожить без неё - зачем зря тратить время?

в которых ровно 1 юзабельный метод — антипаттерн

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

Программисты пишут на языках программирования, а не скриптования.

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

По мне так асинк/авэйт – та ещё шляпа. Фигня на палочке.

Потому что «уйти с уровня школоты»

судя по темам/каментам: написал явный школотон

«изучить нормальный язык для серьёзных проектов» (и нет, это не питон).

ну, например, наколенный оконный менеджер на C - это ни разу не серьёзный проект (да и C нормальным можно назвать с натяжкой: небезопасный легаси макроассемблер для PDP, который всё пытаются натянуть на современные многоядерные системы, шо ту сову на глобус)

набросать что-то побыстрому и незатратно (в плане мыслительных ресурсов кодописателя)

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

Пиши на Go или Rust. Это процедурные, примитивные языки. Их как раз и создали для тех кому лень учить ООП. Python, JS, Ruby - это полностью объектно-ориентированные языки как бы не считали отдельные упоротые. Все-таки это эволюция со сл этапами:

• ассемблеры
• процедурные языки
• ООП и функциональщина
• ну и всякие DML типа SQL

зачем нормальным программистам ООП?

В некоторых задачах удобно.

кучу времени приходится тратить на то, чтобы хоть как-то худо бедно осилить C++ и ООП, а жизнь одна….

Враньё.

Софт не должен быть быстрый, он должен быть good enough по скорости

Верно, а измерения следует производить на системе с CPU 80386 40MHz, памятью 16MB и безлимитным, но медленным жёстким диском.

Была такая игрушка классная Space Empires V, в которую я могу играть на без тормозов на древнем атлоне xp 2500+, и которая тормозила на моем Ryzen 2600… Не всегда проверять быстродействие на процах прошлых поколений лучшая идея

SQL ужасно тупой и вообще не из этого списка. Это эволюция

• рыба
• крыса
• пернатый ёжик
• таракан

Неказистый, кривой, косой, непропорциональный.. Вдобавок, ужасно тупой._

SQL

Софт не должен быть быстрый

А ты должен быть унижен, отпизжен и уволен.

Софт не должен быть быстрый

Чуть помедленнее, Кони. Чуть помедленнее.