JetBrains опубликовали результаты своего исследования экосистемы разработки за 2021 год.

Кроме ключевых результатов, которые на скриншоте, мне показалось интересным еще вот это:

* 53% питонистов занимаются веб-разработкой, и лишь 31% занимаются дата саенсом и машин лёрнингом (это всё равно заметно больше, чем в других экосистемах).
* О миграции на Python задумываются в основном программисты на языках, задействованных в веб-разработке (JS, TS, PHP, SQL). Питонисты же интересуются миграцией на Go, Kotlin, TS и Rust.
* Гоферы сильнее всего интересуются Rust.
* В Индии самым популярным языком является Python. Да, даже популярнее C++, вопреки распространённым мифам.
* В азиатских странах (Китай, Южная Корея) много джавистов, а в Турции C# заметно популярнее других языков.
* В США средние зарплаты в ~2 раза выше, чем в Канаде и Англии, и в ~5 раз выше, чем в РФ.
* В свободное время программисты больше всего любят играть в видеоигры и программировать. Мы за ЗОЖ (задротский образ жизни), так держать!

#jetbrains

В том же исследовании была часть для тех, кто указал Python основным языком. Это намного беднее отдельного исследования про питонистов, которое тоже проводит JetBrains (самые свежие результаты есть за 2020 год). Всё равно интересные данные.

#jetbrains

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

* Большинство проектов всё ещё разрабатываются либо как хобби, либо как пет-проекты. Это объясняет, почему проекты на этом языке чаще всего разрабатываются в одиночку. Только 16% разработчиков пишут на расте на работе.
* Большая часть людей только вкатывается в язык (от 1 до 6 месяцев).
* Большинство разработчиков на Rust пишут код в VS Code. Код часто дебажится принтами, но среди пользователей CLion заметно выше процент использования визуального отладчика.
* Среди разработчиков на Rust намного выше вовлеченность в опен-сорс, чем в среднем по больнице.

#jetbrains

Это, конечно, уже давно не новость, но тем не менее.

У робота Spot от BostonDynamics есть Python SDK, позволяющее им управлять. Других SDK производитель не поставляет.

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

Если работаете с Python и PostgreSQL, то точно знакомы с psycopg2. Вот уже наверное 15 лет это самый популярный драйвер для постгреса на питоне. Де-факто стандарт.

Циферка 2 в названии указывает на вторую версию. Сейчас автор библиотеки (Daniele Varrazzo) очень активно работает над следующей, третьей версией, написанной с нуля, несовместимой с предыдущей версией, зато с новыми полезными фичами и исправлениями давних решений в плане API и принципа работы.

Например, psycopg3:

* поддерживает async/await из коробки; пожалуй, учитывая позитивный опыт работы с psycopg2, я делаю ставку на этот драйвер для асинхронных приложений (aiopg и asyncpg далеко не идеальны, к сожалению);
* полностью обмазан тайп-аннотациями 🥰;
* умеет делать подготовленные выражения (prepared statements) и курсоры на стороне сервера.

Вот тут можно посмотреть презентацию новой версии от автора: https://www.youtube.com/watch?v=XH5_Hc_BHaE

А вот здесь инструкция, как можно установить и пощупать бета-версию уже сейчас: https://twitter.com/psycopg/status/1410221901323063299?s=20

#psycopg

Вот так в psycopg2 передаются параметры в запрос. Это называется биндинг. Это правильный способ, так надо делать. Обратите внимание, это не форматирование строк через процент (старая фича языка, но до сих пор поддерживается)!

А если собирать запрос вручную при помощи f-строк или конкатенаций, и где-нибудь забыть заэкранировать значение, которое ввёл юзер, то будут SQL-инъекции, и все ваши данные либо будут безвозвратно удалены, либо будут потом продаваться по аукционам в даркнете. Так не надо делать.

Похоже, в отличие от меня, половина людей все-таки внимательно читает документацию (хотя я так и не нашел, где бы это было упомянуто явно), и знает, что psycopg2 делает client-side binding. Для меня это сегодня стало новостью. Я почему-то был уверен, что psycopg2 просто делегирует подстановку данных в запрос серверу БД через подготовленные выражения.

В целом, наверное, нет особой разницы, где происходит подстановка данных в запрос. Если на стороне клиента это сделано хорошо, то оно может быть точно так же безопасно, как и server-side binding. Но всё-таки остаётся какая-то вероятность, что psycopg2 вычищает/экранирует не все опасные символы из данных. Вот будет веселье-то, если вдруг такое обнаружится. А если данные попадают в уже распаршенный запрос на стороне сервера, то это уже гарантированно, что они не смогут поменять логику запроса (уже слишком поздно для этого).

psycopg третьей версии будет делать server-side binding, хотя для нас (программистов) интерфейс не поменяется.

#psycopg

Клиент создаёт в СУБД подготовленное выражение

#meme

Классическая пикча с XKCD по поводу SQL-инъекций.

В документации к psycopg2 велят распечатать эту картинку и повесить над рабочим местом.

https://xkcd.com/327/

#xkcd

Introducing PyCharm 2021.2!

#jetbrains #pycharm #nothabr
#news #releases #newsletter

Сегодня узнал, что в Python есть оптимизатор, который на этапе компиляции исходников в байткод избавляется от разных тривиальных инструкций. Например, он вырезает недостижимый код (if False: ...) и предвычисляет выражения, состоящие из одних констант (x = 2 + 2 заменится на x = 4).

Кстати, канал на ютубе у Anthony Sottile крутой.

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

И вот еще статья про эти оптимизации: https://levelup.gitconnected.com/optimization-in-python-peephole-e9dc84cc184d

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

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

В статье есть примеры того, как можно неочевидно удариться об одну из оптимизаций, применяемых в CPython — интернирование. Ну и другие странные, неочевидные примеры.

Хотя случайно так, пожалуй, всё-таки не напишешь.

https://habr.com/ru/post/564804/

Хорошая подборка хороших принципов, которые помогут сделать код лучше, правильнее и чище. Для начинающих программистов — маст рид.

https://habr.com/ru/post/564598/

Чем больше линтеров, тем лучше

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

Чтобы у разработчика не было соблазна скатиться в написание букв, нужно автоматизировать как можно больше рутинных операций. И важнейшая рутинная операция, которую надо автоматизировать, — проверка качества кода. Для понимания, насколько это для меня важно, — в нашем стартере для Django сейчас используется больше 20 плагинов к базовому flake8.

Помимо базовых линтеров, которые проверяют форматирование, типа правильных запятых и кавычек, я использую высокоуровневые линтеры — измеряю когнитивную сложность методов, использую плагин к pytest, который проверяет, что все задекларированные фикстуры используются в тестах. Есть и более высокоуровневые — к примеру, на фронте у нас запрещено использовать название переменной this.$axios, чтобы программисты понимали, что на бекенд надо ходить через отдельные сервисы.

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

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

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

Делитесь в комментах, какими линтерами/плагинами вы пользуетесь. Если вдруг не нашли подходящего, то тоже делитесь.

Закон Кернигана. Чистая истина.

Ценные советы по поводу написания комментариев в коде.

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

https://stackoverflow.blog/2021/07/05/best-practices-for-writing-code-comments/