LINUX.ORG.RU

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

 , , , ,


2

1

Привет, всем. По работе смотрю новые питоновские проекты, и немного удивляет следующие детали:

  1. по сей день, пытаются все оформить сугубо через def() и форкать разные Py-скрипты через систему

  2. не смотря на наличие async/await в Python v3 - не используют и не пытаются

  3. если и объявят class , то он сугубо используется для DAO/DTO, ни каких сложных ОО-дизайнов не оформляется… type hints не испольуются, ABC-контракты не используются, GoF-паттерны тоже

  4. прикрываются якобы композицией, и что вообще ОО-дизайн - мертвый дизайн (у Golang лагеря насмотрелись, что ли?)

Говорю не про публичные проекты, которые в GitHub можно найти. А про многие, которые делает разработка в рос. компаниях. Картину наблюдаю на разных компаниях в течении последних двух лет.

Вот, я не пойму… Я что-то не понимаю или что? Вроде, появляются различные интересные фичи в Python3 , ряд вещей позволяет приблизится к написанию кода, как на Java.

Все-таки, Python не является Haskell, OCaml или каким-нибудь диалектом LISP. Это язык с элементами функциональщины, а не pure functional language, как Haskell. Так от чего не снабдить свой код asyncio, все граммотно оформить по ОО-дизайну с SOLID-принципами, четко разработь с event loop и прочим… Все какая-то портянка из 100500 глобальных def’ов вижу, в основном, в проектах. Да и вроде… Компании - солидные и платят этим Питонисам 250+ рублей в месяц. А стиль написания такой, за который могли бы уволить джуна в 2010ом, если речь шла про другой стэк (C#, Java).

Вопрос: от чего же в новых питоновских проектах на живой практике многие разработчики не пытаются применить фичи из последней версии языка, и приблизиться к дизайну/стилю кода, как на Java. И вообще, все сделать по канону чистенько, соблюдая SOLID. При наличии уже таких возможностей.

Это лень и нежелание просто? Или есть объективные причины забить болт на все это, и далее оформлять спагетти-код километровый?

P.S. не удтверждаю, что я - прав. Возможно, я совсем не прав. Я просто реально не понимаю, почему качество Питон-проектов, как было примерно таким 10 лет назад, то таким и осталось… Адепты на других языках, как-то более лучше развиваются в плане чистоты своих проектов. Опять сугубо моё ИМХО.

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

Хотелось бы пруфцов. И статистики про новые проекты с момента выхода 3.5, сколько там асинхронщины, а сколько тредов.

Так от чего не снабдить свой код asyncio, все граммотно оформить по ОО-дизайну с SOLID-принципами, четко разработь с event loop и прочим…

Да, потому что асинхронщина в питоне совсем не тривиальная. В неё ещё въехать надо, а не просто async/await по коду расставить.

vvn_black ★★★★★ ()

Потому что нормальные программисты, если им нужно ООП, пишут на С++. Ну или, на худой конец, на уже упомянутой джаве или C#.

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

ряд вещей позволяет приблизится к написанию кода, как на Java.

Вобщем-то тут и кроется разгадка. Хочешь писать как на джаве - бери джаву.

firkax ()
Ответ на: комментарий от vvn_black

vvn_black ★★★★★ (19.11.21 14:53:52) Хотелось бы пруфцов. И статистики про новые проекты с момента выхода 3.5, сколько там асинхронщины, а сколько тредов.

Я написал след. в основном сообщении треда:

Говорю не про публичные проекты, которые в GitHub можно найти. А про многие, которые делает разработка в рос. компаниях. Картину наблюдаю на разных компаниях в течении последних двух лет.

То что есть публичные проекты, где все четенько - такое есть, признаю. Речь шла сугубо про приватные проекты компаний. Пруфов дать не могу, ибо проекты - приватные. И публиковать приватный код (а) - свинство , (б) - нарушение закона с моей стороны.

Смысла просто так обсирать - у меня нет. Для меня это скорее «боль и мат», я искрене хотел бы, чтобы питонвские проекты, которые я вижу в компаниях были лучше. Посему и написал такой тред, от боли…

vvn_black ★★★★★ (19.11.21 14:53:52) В неё ещё въехать надо, а не просто async/await по коду расставить.

Ну дык… А почему на других языках, в тех же C#/Java/C++ вполне себе народ въезжает и разбирает все связанное с асинхрохнкой и многопоточностью. А в случае Питона - 100500 глобальных def’ов и форкать через систему? Об этом и вопрос основной с моей стороны.

P.S. Питон я не гажу, для меня это замечательный язык. Искрене не понимаю, почему Питонисты на работе своей не хотят юзать всю его красоту по полной программе.

twinpeaks ()

почему не как в джава? почему редко используют async/await

забить болт на все это, и далее оформлять спагетти-код километровый

Серьезно, ты надеяшься уменьшить лапшичность кода с помощью async/await и перехода на java стиль? На стиль самого лапшичного языка? Ты уж определись чего ты хочешь.

Предьява про async/await вообще странная. async имеет конкретную область применения и тащить его всюду просто что б было очень странная затея. Вот например веб-сервер ты пишешь, что ты собрался распараллеливать кроме IO самого сервера и походов в базу/кэш? А если это не веб, что вообще ты будешь async-ать?

Aswed ★★★★★ ()

пытаются все оформить сугубо через def

https://www.youtube.com/watch?v=o9pEzgHorH0

async/await в Python v3 - не используют и не пытаются

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ . Асинк без причины добавляет проблем.

ни каких сложных ОО-дизайнов не оформляется

Софт, где нужны сложные ОО-таксономии, как правило, слишком сложен чтобы писать его на питоне

type hints не испольуются

Зачастую потому, что на питоне избегают писать сложные вещи, а в прототипах и мелких скриптах type hints опциональны. Я бы сказал, что type hints — это когда софт на питоне внезапно стал слишком большим, переписывать его уже поздно, а ментейнить как-то надо.

GoF-паттерны

зачастую специфичны для java и нафиг не нужны в питоне (или, скажем, в kotlin). Смотреть сюда: https://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures

почему качество Питон-проектов, как было примерно таким 10 лет назад, то таким и осталось

Потому, что юзкейс питона — прототипы и мелкие скрипты. В крупных проектах его юзают разве что из-за того, что слишком поздно переписывать. Хочется нормальный код — есть f# (ну, c# в крайнем случае), kotlin (современная java в совсем крайнем случае), swift, если совсем хочется хипстерских языков — тайпскрипт. Не питон. Питон неплох в своей нише (хотя современные языки постепенно убирают часть её, тот же golang). Но это не java.

x3al ★★★★★ ()
Последнее исправление: x3al (всего исправлений: 1)
Ответ на: комментарий от twinpeaks

Речь шла сугубо про приватные проекты компаний. Пруфов дать не могу

Я тын, пруфов не будет (с)

Не знаю, я вот последние несколько лет вижу норм код. С ОО дизайном, type hinting и асинхронщиной если надо. Может у тебя просто выборка неправильная?

Aswed ★★★★★ ()
Ответ на: комментарий от twinpeaks

Смысла просто так обсирать - у меня нет. Для меня это скорее «боль и мат», я искрене хотел бы, чтобы питонвские проекты, которые я вижу в компаниях были лучше. Посему и написал такой тред, от боли…

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

Ну дык… А почему на других языках, в тех же C#/Java/C++ вполне себе народ въезжает и разбирает все связанное с асинхрохнкой и многопоточностью. А в случае Питона - 100500 глобальных def’ов и форкать через систему? Об этом и вопрос основной с моей стороны.

Потому что в C#/Java/C++ по-другому невозможно. Классы принудительны, половина паттернов тоже, так как через них используется стандартная библиотека. Но для небольших задач это скорее недостаток.

monk ★★★★★ ()
Ответ на: комментарий от Aswed

Aswed ★★★★★ (19.11.21 15:15:18) Серьезно, ты надеяшься уменьшить лапшичность кода с помощью async/await и перехода на java стиль? На стиль самого лапшичного языка? Ты уж определись чего ты хочешь.

Ты бы вместо акцента внимания на «серьезно», давай еще помогу :) «что это было?» ты забыл добавить, а еще выпучить глаза и пустить 100500 слюней, как после лоботомии.

А теперь по сабжу. Я вообще-то там написал SOLID несколько раз, и про GoF. Вопрос к тебе встречный, а что ты пристал к async/await? Если в сообщении о дизайне я упоминал о SOLID/GoF?

Теперь, к async/await. На 2021-ый код уже сложно представить картину, что они тебе не нужны. В большинстве случаев требуется асинхронное исполнение + примитивы синхронизации. Это, если мы говорим о серьезных задачах, ес-но. А не о 5-10 строчных скриптах на мелкие действия.

Aswed ★★★★★ (19.11.21 15:15:18) Предьява про async/await вообще странная.

Нет. Объясню, в контексте промышленных задач, с большой долью вероятности тебе он понадобится. В свою очередь скорее всего, понадобиться еще подтянуть ряд других вещей. Ну банально даже если тебе нужно в РСУБД работать из различных источников. Преобразовать DAO<->DTO через AutoMapper, агрегировать с различных источников данные, преобразовать их. Иметь различные реализации, где кстати тебе инверсия зависимостей понадобиться.

Все это, как правило дергает одно за другое. И в конечном итоге, в промышленной задаче - тебе понадобиться всё. И знания, как красивый дизайн оформить, чтобы иметь возможность поддерживать ПО в течении нескольких лет, а не пописать что-то полгода и выбросить. Ну и… Хочешь-не хочешь, необходимость правильно оформить дизайн работы через asyncio с правильным дизайном, тебе тоже придется. Посему… Не вижу ничего неправильного. Сорри.

Aswed ★★★★★ (19.11.21 15:15:18) А если это не веб, что вообще ты будешь async-ать?

Что есть в твоем понимании «вэб» ? Да, хотя бы взять вышеуказанные пример с базами… Может быть вообще ситуация, что ты пишешь не для вэба проект, который должен участовать в сложных ETL-процессах, заниматся выборкой данных и прочим. Тут тебе async не нужен будет? Будет еще как… Пойдет вообще огромная необхиодимость в моделях синхроиназции. И причем тут «веб» ?

twinpeaks ()
Последнее исправление: twinpeaks (всего исправлений: 1)
Ответ на: комментарий от Aswed

Aswed ★★★★★ (19.11.21 15:18:03) Я тын, пруфов не будет (с)

Прочитай еще раз, что я написал ранее:

То что есть публичные проекты, где все четенько - такое есть, признаю. Речь шла сугубо про приватные проекты компаний. Пруфов дать не могу, ибо проекты - приватные. И публиковать приватный код (а) - свинство , (б) - нарушение закона с моей стороны.

Т.е., чтобы лично тебя успокоить, я должен тебе прислать сырцы или скриншоты приватных проектов? :) Не говори ерунды, мне не надо, чтобы нагуглили данные исходники и скриншоты. Не хочу проблем. Поэтому… Уж, как хочешь верь. Хотя, я думаю что кто часто работает с Питон-проектами, подтвердит что я не говорю выдумку, т.к. в компании матерюсь не я один на эту тему.

P.S. еще раз повторю на всякий случай:

  • Python - хороший язык и он мне нравится
  • я не обсираю всех питонистов, а сугубо то вижу на фирмах последние два года… возможно такой контингент, возможно сам не вижу
  • доказывать что-то пеной у рта насчет пруфов не буду, ибо приватные проекты… не верите - ок, как-нибудь переживу
twinpeaks ()
Ответ на: комментарий от twinpeaks

Может быть вообще ситуация, что ты пишешь не для вэба проект, который должен участовать в сложных ETL-процессах, заниматся выборкой данных и прочим. Тут тебе async не нужен будет?

Ну. В случае с питоном вне веба зачастую 90% времени тратится не на «ждём IO», а на «тормозим на одном ядре (GIL) питоном, опционально: умножить на N процессов чтобы тормозить на всех ядрах». Смысл в async если время ожидания IO минимально по сравнению с обработкой в самом питоне?

x3al ★★★★★ ()

Покажи нам примеры хороших проектов на Java.

Или, если это секрет, формальное доказательство, что использование GoF patterns и async/await реально приводит к лучшему коду (лучшему по какому критерию)?

Ты, кстати, неужели не знаешь, что значительная часть GoF паттернов к Python неприменима, потому что они были созданы для компилируемых языков со статической типизацией, и в интерпретируем языке с динамической типизацией зачастую такие сложности совершенно не нужны?..

emorozov ()

async/await

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

по сей день, пытаются все оформить сугубо через def() и форкать разные Py-скрипты через систему

Потому что питон клей обычно и там не надо много архитектуры, которая к тому же лагать будет как проклятая. Да и не очень уж оно там надо.

если и объявят class , то он сугубо используется для DAO/DTO, ни каких сложных ОО-дизайнов не оформляется… type hints не испольуются, ABC-контракты не используются, GoF-паттерны тоже

Ну я датаклассы использую как они появились, потому что с ними удобнее сложную кашу разгребать. В type hints мало смысла, пока в питон не внесут полноценную статику прямо которая совсем-совсем ругаться будет и не будет давать возможности динамику использовать. Хотя сам питон про динамику и смысла тут не так уж и много, но в теории для дополнительного контроля там где совсем всё сложно может и был бы смысл. А так точно нету. ABC-контракты аналогично, плохо вписываются в текущую типизацию python-а и нужны там почти как собаке 5 нога на спине. GoF паттерны они про чистый ООП, а в питоне ООП не то чтобы чистый... Это тебе не C# и не Java. Python способствует лепить месиво из разных парадигм.

PS

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

peregrine ★★★★★ ()

не используют и не пытаются

  1. Не умеют.
  2. Много легаси.
  3. Не в тех компаниях работаешь, не на те объявления о вакансиях смотришь.

ни каких сложных ОО-дизайнов не оформляется…

Ибо нафиг не упёрлось зачастую. Из ООП давно сделали карго-культ, и очень хорошо, что среди питонеров не так много его адептов.

type hints не испольуются, ABC-контракты не используются, GoF-паттерны тоже

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

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

WitcherGeralt ★★ ()

реально не понимаю, почему качество Питон-проектов, как было примерно таким 10 лет назад, то таким и осталось

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

no-such-file ★★★★★ ()

Падаван, ответы на все твои вопросы есть в Дзене:

по сей день, пытаются все оформить сугубо через def() и форкать разные Py-скрипты через систему
не смотря на наличие async/await в Python v3 - не используют и не пытаются

Простое лучше, чем сложное # Проще вынести нужную параллельность на системный уровень (или на уровень либ)

если и объявят class , то он сугубо используется для DAO/DTO, ни каких сложных ОО-дизайнов не оформляется…
ABC-контракты не используются, GoF-паттерны тоже
прикрываются якобы композицией, и что вообще ОО-дизайн

Разреженное лучше, чем плотное # Без комментариев

type hints не испольуются

Красивое лучше, чем уродливое # Код без ручной аннотации типов выглядит чище и пишется быстрее


P.S. Чтобы прочитать Дзен, выполни >>> import this

Crocodoom ★★★★ ()

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

Ох, я такого в Java-проектах в рос. компаниях насмотрелся, ты б знал.

anonymous ()

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

bhfq ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

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

firkax ()
Ответ на: комментарий от izzholtik

А что делать, если язык — прослойка для проектов на нормальных других языках?

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

fernandos ★★★ ()

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

import foo
foo  # <- вот это синглотон

it = iter([1,2,3])  # а это итератор!


# мы можем передавать сам класс как аргумент и уже фабрика не фабрика
def fabric(klass):
  ...

# на так же не нужны интерфейсы, так как питон позволяет множественное наследование

и так далее и далее по списку

tz4678 ★★ ()
Ответ на: комментарий от tz4678

так был убит php

В ваших влажных фантазиях. Или вы из тех, кто постит на реддите темы про god old php? Нет уж, пхп прекрасно развивается и совершенствуется.

//А сейчас ещё динамические свойства признают устаревшими, всё лучше и лучше.

fernandos ★★★ ()
Ответ на: комментарий от fernandos

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

firkax ()
Ответ на: комментарий от fernandos

Вообще, как я понимаю, обычно асинхронный код часто нужен в фронтенде, чтобы интерфейс не подвисал на ожиданиях выполнения кода. Когда нет возможности в среде исполнения использовать обычный многопоток - типа js. Зачем в питон делать асинхронные вызовы? Он не используется во фронтенде же вроде и нет никакого ограничения на создание потоков.

xmikex ★★★★ ()
Ответ на: комментарий от fernandos

define как на джаве.

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

firkax ()

ООП, как в Java?

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

То же самое касательно async/await - далеко не везде оно нужно. Хотя насчёт type hints полностью поддерживаю. Завёл привычку всегда писать type hints в объявлениях функций - волосы стали мягкими и шелковистыми.

eternal_sorrow ★★★★★ ()

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

Грабли и вилы в мерседесе пользы не принесут, а большой горшок может и понадобиться …

anonymous ()
Ответ на: комментарий от peregrine

В питоне так-то однопоток и GIL, а в таких условиях асинхронность выглядит не так уж и полезной.

Наоборот. Именно в таких условиях event loop выглядит привлекательнее, чем threading, который не даёт тебе настоящих тредов.

eternal_sorrow ★★★★★ ()

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

Если при исполнении симфонии будут часто бить в литавры и барабан, то

зрители в УЖАСЕ все РАЗБЕГУТСЯ  

Что до корпораций, то Ж..ТЕ, что дают …
У них первейшая потребность -
Что нибудь разработать и

ВСУЧИТЬ
anonymous ()
Ответ на: комментарий от eternal_sorrow

но питон же это и есть ооп, только нет объекта верхнего уровня свойствами которого были бы все объявленные объекты как в js или ruby:

➜ node -e "function foo(){}; console.log(this.foo)"               
[Function: foo]
tz4678 ★★ ()
Ответ на: комментарий от tz4678

но питон же это и есть ооп

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

eternal_sorrow ★★★★★ ()
Ответ на: комментарий от xmikex

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

tz4678 ★★ ()