Классическая пикча с 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/

Очередная минутка JetBrains.

CodeWithMe — инструмент для парного программирования для удалёнщиков — обновился и обзавёлся новыми фичами и багфиксами. Теперь там можно шарить экран, чтобы коллеги могли видеть не только IDE, но и, например, браузер. А ещё можно расшаривать сетевые порты с хостовой машины на всех гостей, так что, например, один из разработчиков пишет код, другой в это время расшатывает вам базу данных, а третий шлёт в ваш замечательный сервис HTTP-запросы через свой любимый Postman.

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

https://blog.jetbrains.com/blog/2021/08/04/what-is-in-code-with-me-2021-2/

#jetbrains

Забавно, GitHub Copilot умеет выдавать небольшие текстовые квесты целиком.

https://sandyuraz.com/blogs/copilot-game/

Пост про историю миграции Mercurial с Python 2 на Python 3.

Mercurial — это примерно как Git, но написано на питоне. Есть у этой системы контроля версий свои поклонники.

Они начали постепенно переходить с Python 2 ещё 2008 году, когда только вышел Python 3.0, но активно работали над поддержкой Python 3 только с 2015 года. В общей сложности миграция заняла 11 лет, из них 5 лет активной работы. Это, конечно, эпохально. Само собой, в это же время параллельно проект обрастал новыми фичами, а миграция до последнего момента была лишь фоновым, неприоритетным процессом.

Наивно было полагать, конечно, что получится поддержать третью версию языка, сохраняя совместимость с 2.5 и 2.6. Отказ от очередной старой версии языка давал ощутимый буст в сторону миграции на Python 3. Сам язык тоже активно мешал плавному переходу и поддержке нескольких версий одновременно. По сути, более-менее безболезненно перейти стало можно только с 2.7 на 3.5. Всем версиям до 3.5 не хватало какого-то важного элемента для обратной совместимости. Больше всего чуваки намучались со строками-байтами.

Автор делает серьёзные выводы, что годы с 2008 по 2015 можно считать потерянными для Python-сообщества. Мейнтейнеры языка сильно недооценили сложность перехода со второй версии языка на третью, и это вылилось в катастрофу, последствия которой мы испытываем до сих пор. Несомненно, третья версия значительно лучше второй, но какой ценой. Эти годы могли бы быть потрачены с куда большей пользой. Язык смог пережить этот переход лишь благодаря тому, что Python 2.7 был силён и весь из себя хорош на протяжении всего этого болезненного периода, и люди могли им пользоваться, сохраняя лояльность к языку.

По итогу автор заключает, что для проекта Mercurial этот переход был настолько болезненным и затянувшимся, что даже не факт, что оно всё того стоило. Качество кода после миграции, увы, только ухудшилось. Теперь еще несколько лет вычищать слои совместимости, которые были нужны для поддержки питона 2. А новых классных фич языка, полезных для проекта, не прибавилось (только тайп аннотации). Кроме того, Python 3 даже принёс им дополнительных проблем, потому что низкоуровневый код стало писать сложнее из-за Юникода по умолчанию. По сути мигрировали вынужденно лишь бы не остаться на неподдерживаемой версии языка. Говорит, если бы тогда, в 2014, Rust был бы так же хорош, как сейчас, то лучше бы мигрировали сразу на него.

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

Я пришёл к питону по сути не так давно, когда третья версия уже доминировала. Я, конечно, потрогал вторую версию, и знаю все (наверное) различия между 2 и 3, но я не думал, что этот переход был прямо настолько болезненным процессом. Для меня сегодня стало открытием, что версия 3.0 была настолько несовместимой, что там даже убрали префикс u"" для юникодовых строк, что вкупе со сменой типа для строк с байтов на юникод по умолчанию делало фактически невозможным написание кода, работающего на обеих версиях языка. До какого-то момента в Python 3 не было форматирования для байтовых строк через %, что тоже доставляло немало страданий. Похоже, изначальный план миграции действительно был такой, что люди просто резко перепишут весь свой код на Python 3, а вторую версию языка можно будет спокойно выкинуть. Лишь через несколько лет и несколько мажорных релизов появилась и нормально заработала эта идея универсальных библиотек, совместимых с обеими ветками языка, что позволило и конечным проектам тоже постепенно переписываться, шаг за шагом, не ломая совместимости со старым языком, продолжая приносить пользу. Появились прослойки совместимости, типа six. Если бы такая тактика была выбрана изначально, то, вероятно, миграция закончилась бы намного раньше и прошла бы куда плавнее. Может быть за эти 7 лет сообщество успело бы развить хорошую экосистему пакетирования библиотек, а не тот хаос, который мы имеем сейчас. Или асинхронщина была бы постабильнее и повылизаннее. Язык и так популярный и крутой, но мог бы быть ещё популярнее и круче, если бы не было потрачено столько сил на миграцию. Если бы, если бы, если бы.

Люблю угарать над проектами и командами, которые так и остались на втором питоне. Я отлично понимаю, что это самые несчастные люди среди нас всех, но они сами себе злобные буратины. Мне самому скорее повезло не иметь дел со вторым питоном, хотя я бы на это уже и не согласился ни за какие коврижки. Именно из-за этих буратин, коих осталось меньшинство, многие популярные библиотеки до сих пор держат совместимость со старым языком, лишая большинство своих юзеров новых классных фич (например, urllib3, requests и boto3, у которых тайп-аннотации до сих пор доступны лишь через типизированный сарай). И мы до сих пор продолжаем вспоминать старое, потому что оно не уходит. А ведь хотелось бы давно уже про всё это забыть. Поэтому я и шучу про ретроградов, чтобы не было так печально. И продолжу шутить, пожалуй.

Ладно, вторник — день тяжелый, поэтому не буду вас сегодня грузить сложными постами. Сегодня культурно просвещаемся.

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

Отсылки к этому шоу есть не только в названии языка, но и много где ещё в экосистеме. Вообще, разработчики языка любят всяческие каламбуры и пасхалки. Например, PyPI — индекс пакетов — изначально назывался "cheese shop" в честь вот этого комедийного скетча. Сырный магазин для дворян и бедняков, в котором нет сыра. Это сейчас там миллионы библиотек, а изначально PyPI был очень бедным и пустым. Нынешняя версия PyPI называется "warehouse" (большой магазин, товарный склад), видимо, потому что там теперь много всего.

Кстати, бинарный формат библиотек "wheel" тоже так называется в честь колёс сыра. Ещё это название можно расценивать как отсылку к фразе "не переизобретай колесо", ведь в PyPI много готовых колёс. А ещё колёса не нужно пересобирать, они уже собраны.

#montypython

Говорят, полезно смотреть Монти Пайтона.

https://docs.python.org/3/faq/general.html#do-i-have-to-like-monty-python-s-flying-circus

Крутейшее объяснение алгебраических типов данных в Python.

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

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

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

Python и отсутствие претендентов

Буквально вчера общался со знакомым .NET-разработчиком, мне во всех красках было описано какой F# замечательный ЯП, почему он превосходит С#(основной инструмент .NET-разработчиков), и почему за ним, очевидно, будущее отрасли.

Разумеется все эти разговоры, что в будущем все предпочтут его C# - крайне спорная штука. Мы все прекрасно понимаем, что все упрется в задачи бизнеса, и если бизнесу будет выгоден такой переход, то он случится, аналогично и обратное(вот такая она суровая реальность).

Однако F#, действительно мощный претендент на место, в каком то смысле это переосмысление, возможно неоднозначное(все таки смена парадигмы), но при этом вполне конкурентоспособное. Он можно сказать дышит в спину C#.

Так вот, довольно интересно, то что буквально все “главные” ЯПы сейчас имеют таких “конкурентов”. 

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

Java -> Kotlin
C++ -> Rust ежегодно на stackoverflow проходит опрос программистов, и именно этот ЯП лидирует как самый любимый у разработчиков(отрыв от второго места - солидные 20%)
С# -> F#
Js -> TypeScript и Dart

И только питон выделяется из всех, у него вроде как подобных ‘конкурентных’ аналогов нет. Есть много экспериментов на тему ‘так чуть красивше/чуть удобней’, но чего-то серьезного - нет. Справедливо сказать, что таким претендентом в свое время стал сам Python 3, потеснив Python 2, но во-первых, это случилось не вчера, во-вторых, этот пример все равно отличается от выше перечисленных.

Это не значит, что питон лучше/хуже других ЯПов(подобные оценки с инженерной точки зрения просто нелепы), но это значит, что путь развития питона крайне необычен. И судя по реакции сообщества, это движение в верную сторону. И как по мне, это весомый плюс языка, о котором редко говорят.
#python #мысли

Среда это маленькая пятница, поэтому вот вам немного пятничный пост.

1. Откройте в web гитхаба любой проект (например https://github.com/python/cpython)
2. Нажмите . (кнопка на клавиатуре, точка)
3. Вы прекрасны

#pydaily #nothabr