LINUX.ORG.RU

Есть ли годные гайды по стилю для питона

 , ,


1

2

Я внезапно осознал, что толком не могу сформулировать, какие фичи питона стоит использовать, а какие — нет (как в последнем треде по крестам). Ситуация усложняется тем, что нынче каждая вторая собака считает себя гуру питона и готова учить других, но только единицы умеют по-настоящему хорошо пользоваться языком. Я могу открыть очередную сессию экспертов LOR следующими правилами:

  • Не используй monkey patching (изменения классов и функций в процессе работы приложения) без крайней необходимости;
  • Не используй классы, если это не навязывает библиотека и тебе не нужно переопределить операторы, предпочитай duck typing. Следствие — статическая типизация в питоне не работает;
  • Лямбды — говно, и функциональная парадигма в питоне близка к неюзабельности из-за трудности передачи блока кода аргументом. Язык изначально ориентирован именно на импертивный код аля «башпортянка», потому предпочитай list comprehension/generator expression вместо filter-map;
  • Предпочитай пересоздавать простые значения с нужным типом, а не передавать их как есть или по ссылке. При изменении значения ячейки используй новые значения, а не изменяй старые обьекты. Под капотом CPython уже создает-высвобождает объекты на каждый чих. Создать строку из строки в питоне стоит примерно ничего, но если внезапно вместо строки подвернется непонятный тип или None, то код рискует свалиться со стэком в неожиданном месте.

PS: мои прошлые работы по теме, которые дают советы «как не делать», но не дают советов «что же делать»:

Объектная модель питона
https://habr.com/ru/post/481782/ - О проблемах транслятора Python и переосмысление языка

Перемещено leave из talks

★★★★

Последнее исправление: byko3y (всего исправлений: 1)

Ответ на: комментарий от byko3y

Кстати, что ты под этим имеешь в виду? Раздувать код в два раза только ради того, чтобы дать кодеру подсказки?

Везде - в каждом месте где это не очевидно, т.е. как минимум сигнатуры и каждая точка где ide теряет тип (например пичарм его теряет на asyncio gather). И скорее заставить кодера самого раздуть код в два раза чтоб самому себе дать подсказки.

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

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

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

upcFrost ★★★★★
()
Последнее исправление: upcFrost (всего исправлений: 1)

Есть ли годные гайды по стилю для питона

Делайте как вам удобно …

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

Я за датаклассы, но против классов — так пойдёт?

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

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

Когда-то работал с командой индусов, заработал аллергию на питонов (и на индусов). Я вообще с программированием завязал, так что моё мнение очень «ценное». Иногда почитываю код впрочем, и вижу какое у программистов горе от ума+

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

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

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

Везде - в каждом месте где это не очевидно, т.е. как минимум сигнатуры и каждая точка где ide теряет тип (например пичарм его теряет на asyncio gather). И скорее заставить кодера самого раздуть код в два раза чтоб самому себе дать подсказки

А, так проблема в том, что PyCharm тупорылый. Ты заставляешь кодера служить PyCharm, а не PyCharm кодеру. Самая эффективная вещь, которую делает тот же PyPy — это трассирующая типизация, то есть, прогоняется программа, записываются фактические сигнатуры объектов. Не класс, потому что в питоне класс часто не играет роли, а фактические атрибуты. Это то, что в V8 именуется «скрытый класс».

На деле когда человек пишет хинты для сигнатуры и в return у него идёт union из строки, списка и словаря - обычно даже не приходится объяснять почему говнокод и почему надо исправить

То, что не нужно такой трешак писать, это собственное правило, к сигнатурам оно вообще никакого отношения не имеет.

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

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

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

Ну и статья от 2012 года, подтухла мягко говоря

Да питон в 2021 абсолютно тот же самый, и говнокод такой же.

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

почему функциональное погромирование в питоне не работает.

Работает на уровне «в key= передаётся функция».

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

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

В питоне слишком тупой дефолтный интерпретатор чтобы делать что-то лучше.

Навевает мысль, что Питон для …

anonymous
()

Через тысячу лет уфологи в книгах по истории будут описывать какие технологии использовали древние человеки … /и за Python вспомнят/

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

перепеши

Ты оплатишь время на переписываение? И портируешь недостающие библиотеки, которые есть в питоне, но аналогов нет в твоём маргинальном язычке?

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

Ты заставляешь кодера служить PyCharm, а не PyCharm кодеру

Ты упускаешь из виду что кодеров больше одного. Мне нужно чтоб каждый кодер видел аннотации для кода, написанного соседом. Кому им для этого придётся служить меня не особо волнует

Самая эффективная вещь, которую делает тот же PyPy — это трассирующая типизация, то есть, прогоняется программа, записываются фактические сигнатуры объектов.

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

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

Тут на 90% согласен, возможность проверить тип таки есть, пусть и не со 100% гарантией. Но гарантию тебе даже жаба не даст, там через type erasure тоже можно много веселья протащить

То, что не нужно такой трешак писать, это собственное правило, к сигнатурам оно вообще никакого отношения не имеет.

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

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

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

с такой командой ты получишь гарантированную аллергию на любой используемый ЯП

Да там не дураки были, просто на динамике мало кто может писать нормально. А в питоне еще полно подводных камней, как нигде. Вся остальная пыхоплеяда куда проще.

bread
()
Ответ на: комментарий от byko3y

При чем тут ститическая типизация к namedTuple и dataclass? Они затыкают дырку в виде отсутствие удобных примитивов составных типов данных в питоне

Ну и позволяют минимумом писанины получить класс с аннотированными полями. Тайпчекер в том же pycharm понимает эти аннотации.

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

использовать аннотации для функций только тогда, когда аннотации типов используются в самом питонячьем коде. На мой взгляд писать аннотации везде -> засорять код мусором

Про мусор согласен, а первый тезис не понял — что такие «когда аннотации типов используются в самом питонячьем коде». А есть не сам?

Мне понравилось использование типов в библиотеке fastapi. В параметрах функции-вьюхи явно указываются типы. Например, вот эта переменная берется из cookie, эта переменная из заголовка, а эта из тела запроса.

Например:

@app.get("/items/{item_id}")
async def read_items(item_id: int, ads_id: Optional[str] = Cookie(None), user_agent: Optional[str] = Header(None)):
    return {"ads_id": ads_id, "item_id": item_id, "user_agent": user_agent}

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

Интересует сей процесс в подробностях

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

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

Ты упускаешь из виду что кодеров больше одного. Мне нужно чтоб каждый кодер видел аннотации для кода, написанного соседом. Кому им для этого придётся служить меня не особо волнует

Проблема в том, что аннотации плана somefunc(int, str, int) практически ничего не говорят. Я всеми ногами за то, чтобы содержание параметров и результата документировалось — я лишь считаю, что аннотации являются плохим инструментом для этой задачи.

Самая эффективная вещь, которую делает тот же PyPy — это трассирующая типизация, то есть, прогоняется программа, записываются фактические сигнатуры объектов.

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

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

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

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

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

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

Да там не дураки были, просто на динамике мало кто может писать нормально. А в питоне еще полно подводных камней, как нигде. Вся остальная пыхоплеяда куда проще

Вот прямо хочется расцеловать, ни секунды не сомневаешься, что человек отхлебнул питонового горя сполна. Хочу еще раз повторить твой же тезис с другой стороны: на динамике, вроде питона, тяжело хорошо писать программы. Это так. Write-only написать легко, как на коболе или фортране или лиспе, только потом что с этим кодом делать? Модульность и читаемость — это как подростковый секс: все говорят и хвастаются, но реально никто в него не умеет, и максимум какую-то бухую телку удалось затащить в кровать разок. Однако же, модульность и читаемость — это фундаментальные определяющие качества кода.

При всем моем неуважении к бесконечным подводным камням питона — это все-таки не оправдание для того, чтобы плохо писать на нем код.

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

Ну и позволяют минимумом писанины получить класс с аннотированными полями. Тайпчекер в том же pycharm понимает эти аннотации

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

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

Никем, бичую в деревне

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

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

Мне понравилось использование типов в библиотеке fastapi. В параметрах функции-вьюхи явно указываются типы. Например, вот эта переменная берется из cookie, эта переменная из заголовка, а эта из тела запроса
async def read_items(item_id: int, ads_id: Optional[str] = Cookie(None), user_agent: Optional[str] = Header(None)):

Так это ж не аннотации, а обычное значение по умолчанию.

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

В питоне ты можешь объекту добавить любое свойство, не описанное в классе.

В PHP можно в run-time добавлять в классы методы … … …
Динамические языки программирования просто обязаны предоставлять в run-time создавать объекты и …
Беда в том, что этот API не очень производителен как и сами объектные модели.
Индустрия меня не много удивляет.
Много судачат о run-time, динамическим объектам, … а до сих пор не имеют вменяемого и производительного API для использования метаданных и функционала, который бы позволил на этих возможностях
произвести разработку обобщенных алгоритмов, которые взяли бы на себя МНОГО РУТИНЫ с которой приходится иметь дело программистам.
Щеки надувают сильно, а API НЭМА.

Не могу понять почему все так.
Как трактористы.
Все знают о тракторе, только не знают куда же в него ЛОШАДЬ ВПРЯГАТЬ …

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

Не понимаю твоей претензии. CLR и V8 прекрасно умеют совмещать высокопроизводительный код с полной динамикой.

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

Не, у меня карьера пунктирная. Где-то в 2003 году можно было идти в начальники, стал бы может толстым буржуем. Но не судьба

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

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

Если ты не слепой алкаш

А если да? А почему ты нетакойкаквсе? Спорим, что если я начну опрос тебя, то мы выясним (и быстро) что бы даже хуже, чем большинство пользователей/заказчиков/клиентов?

Как тогда?

Not_a_Troll
()
Ответ на: комментарий от byko3y

«Жопу рвать не буду я из-за бабок и бабья. Никуда я не спешу, почитаю, попишу.» У меня есть еще интересы кроме пограмизма. А с возрастом пограмизм вообще ушел на десятое место.

bread
()
Ответ на: комментарий от byko3y

Проблема в том, что аннотации плана somefunc(int, str, int) практически ничего не говорят.

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

Почему те же лисперы разрабатывают на работающем приложении

По той же причине по которой они почти все вымерли - лисп никому нафиг не упал. Дебаггер таки основной инструмент разработки. Без подсветки синтаксиса жить можно, а вот без дебага разве что принтами, совсем грустно

именно по этой причине индустрия идет к динамической типизации и выводу типов — чтобы убрать самоочевидные указания типов из кода

Очевидные - да, по сути тот же auto в крестах для того и есть. А вот что-то хоть отдалённо неочевидное (например Id в базе, может ведь и objectId из монги быть) нужно прописывать

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

Вот именно потому в корп разработке все это необходимо, снижает уровень треша

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

И они умеют создавать бинарные файлы на основе объектов и работать с ними как с базой данных?

Да много чего не умеют.

https://v8docs.nodesource.com/node-16.13/classes.html много о чем повествует.

Могу я на динамически создать объект типа конфигурации 1С 8.3, добавить индексы где считаю нужным и производительно работать как в memory, так и с дисковым объектом?

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

Об этом речь ...
anonymous
()
Ответ на: комментарий от byko3y

Какая проблема в любом году идти начальником?

Это для тех у кого

Щеки БОЛЬШИЕ, руки ДЛИННЫЕ /для жестикулирования с трибун/ и ЧСВ ОГРОМНОЕ ...
anonymous
()
Ответ на: комментарий от anonymous

Шутка

Так вот @byko3y у вас

Щеки БОЛЬШИЕ, руки ДЛИННЫЕ /для жестикулирования с трибун/ и ЧСВ ОГРОМНОЕ имеется?  

Если нет, то не быть вам Королевым …

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

Каков инструмент, таковы и работники.

ИМХО в архитектуре 1С много хороших объектов и полезного.
Сама то она СКРИПТУХА, да вот разработчикам полезно понять что хорошего в ней.
Конечно без слепого создания а-ля 1С /ИМХО пустая трата времени/.
Впрочем КОЛЕСО они не изобрели и в целом вроде понятно, какое API нужно разработать для эффективной разработки проектов …

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

Интересно, что на первых девяти. Зимняя рыбалка и почесывание брюха жирному коту Ваське по вечерам?

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

Шутка

@КАПУСТА, я вас уважаю как профессионального программиста.
Что до вашего вопроса, то мне стыдно вас учить …
Лишь пару намеков

 - легко создаются объекты любой сложности и иерархии /и API достаточно производительное/;

 - объекты в 1С позволяют создавать просто эффективные алгоритмы;  

 - ...

Остальное сами домыслите …

И речь не о том, что нужно использовать саму 1С, а о том, что ее разработчики много полезного API создают …

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

Спорим, что если я начну опрос тебя, то мы выясним (и быстро) что бы даже хуже, чем большинство пользователей/заказчиков/клиентов?

Неа, к сожалению, я милашка.

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

«Жопу рвать не буду я из-за бабок и бабья. Никуда я не спешу, почитаю, попишу.» У меня есть еще интересы кроме пограмизма. А с возрастом пограмизм вообще ушел на десятое место

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

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

Не то чтоб я жопу рвал, но приятно жить не особо парясь ни о чем.

Это иллюзия.
Пройдут года и Совесть НАПОМНИТ …

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

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

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

Дебаггер таки основной инструмент разработки. Без подсветки синтаксиса жить можно, а вот без дебага разве что принтами, совсем грустно

Ну вот видишь, а пишешь «типы нужно знать до запуска». Намного важнее иметь предсказуемость, иметь гарантию, что толян внезапно тебе не похерит структуру уже проверенного объекта, а не просто статически проверять классы. А чтобы иметь гарантию правильной структуры — нужно жестко ограничивать места, из которых объект создается и изменяется. К сожалению, весь питон построен из противоположного предположения.

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

и что ты здесь забыл?

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

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

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

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

И они умеют создавать бинарные файлы на основе объектов и работать с ними как с базой данных?

Да.

https://v8docs.nodesource.com/node-16.13/classes.html много о чем повествует

? Что я должен был из этого понять?

Могу я на динамически создать объект типа конфигурации 1С 8.3, добавить индексы где считаю нужным и производительно работать как в memory, так и с дисковым объектом?

Советую сразу определиться, тебе в память или на диск. Потому что они ведут себя совершенно по разному, и те же популярные РСУБД хранят данные на диске и в памяти совершенно по разному. Это когда-то было нужно, когда сервер был один, когда единственной гарантией персистентности был диск. Но в 2021 году можно поставить два сервера, гарантией персистентности будет другой сервер, а в случае полного отказа по таймеру делаем снапшоты. И по итогу структуры данных под такую БД имеют совершенно иной вид (Clickhouse, например).

byko3y ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.