Вышли минорные релизы CPython всех поддерживаемых веток (3.6 — 3.9).

В ветке 3.9 пока фиксятся баги и вносятся прочие улучшения, а вот 3.8 и более старые ветки получают только исправления уязвимостей — найденные баги в эти ветки уже не бэкпортят. Видимо, ожидается, что к настоящему моменту большинство юзеров должно уже перейти на 3.9 (к сожалению, вряд ли это так).

А ветке 3.6 осталось поддерживаться всего полгода, так что с неё нужно обновляться как можно скорее, если вы вдруг все ещё на ней!

https://pythoninsider.blogspot.com/2021/06/python-396-3811-3711-and-3614-are-now.html

GitHub выпускает Copilot, который может дополнять код целыми функциями. Тем временем автодополнение в пайчарме.

Я заинтриговался и таки запросил доступ в техническое превью GitHub Copilot.

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

По поводу популярности версий Python.

Судя по последнему опросу от JetBrains (2020), наиболее популярной является ветка 3.8.

Опросы — это хорошо, но можем ли мы проверить эти данные или получить более свежую информацию? Конечно, можем. Индекс PyPI при установке пакетов собирает анонимную статистику, откуда можно вытащить версии интерпретатора. Эти данные доступны публично напрямую через сервис Google BigQuery, но можно получить их с некоторым отставанием и через HTTP API, например, через сервис pypistats.org (кстати, здесь можно смотреть статистику пакетов и через веб-интерфейс). По количеству скачиваний популярных пакетов мы примерно можем оценить какие сейчас ветки языка в ходу.

Субъективно выбрал пару пакетов, которые кажутся мне популярными и универсальными (т.е. применимы и для веб-разработки, и для data science, и для вообще всего), скачал данные за последние полгода. Нарисовались вот такие графики.

Что видно:
* сейчас на пике популярности находится ветка 3.7 (напомню, там фиксятся только критичные уязвимости, но не прочие баги);
* далее примерно с одинаковым количеством скачиваний идут 3.8 и 3.6 (напомню, ей осталось поддерживаться ещё полгода);
* ~10% наркоманов разработчиков все ещё сидят на Python 2.

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

Честно говоря, я не понимаю, почему есть такое отставание по версиям. Переход между версиями языка 3.X обычно проходит почти безболезненно. Максимум, придётся просмотреть DeprecationWarning'и и вызывать какие-нибудь другие функции. А взамен получаете новые языковые фичи, оптимизации производительности, исправления багов и уязвимостей.

Короче, домашнее задание! Прямо завтра попробуйте обновить ваши проекты до следующей версии питона, а в идеале сразу же до последней доступной — до 3.9!

Издревле бытует мнение, что Windows — это чтобы играть в игры или запускать фотошоп или офис 2007, но для разработчика — это не самая подходящая ОС.

Я отчасти согласен, потому что для многих экосистем Windows не является первоклассным гражданином. Всё вроде бы и работает, но... То есть, например, сам Python отлично работает на Windows, но в документации ко многим проектам все команды написаны исключительно для bash, как будто других шеллов не существует, и тебе приходится адаптировать эти команды к винде, что в сто раз сложнее, чем просто скопипастить. Или разница в файловых системах и кодировках по умолчанию — если хочешь нормально поддерживать несколько операционных систем, то постоянно нужно держать в голове, что где-то в мире сидит тот самый юзер, у которого пути разделяются обратным слэшем, а файлы по умолчанию пишутся и читаются в KOI-8 или cp1251. Или что пути тоже где-то будут не в юникоде. Или что терминал может не поддерживать эмодзи и прочие экзотические символы, а цвета/шрифты в терминале делаются совсем иначе. Или эти чёртовы символы новой строки. Или что где-то может просто не быть файла /dev/null. Кажется, что разработчики многих утилит и библиотек насколько намучались с виндой, что решили просто игнорировать её существование, что опять же ставит пользователей Windows в невыгодное положение.

Но в последнее время всё, кажется, меняется в лучшую сторону. Microsoft почему-то сильно хочет сделать свою ОС привлекательной для разработчиков, они вливают в это очень много сил и денег, и это постепенно даёт плоды. В какой-то момент MacOS перестала быть занозой в заднице, потому что стала Unix-подобной ОС, и на ней внезапно стало комфортно жить разработчикам. Похоже, Windows при помощи WSL пытается сделать что-то подобное. Кроме того, другие части ОС тоже развиваются: попробуйте хотя бы Windows Terminal — это прям действительно удобный эмулятор терминала со вкладками, там даже хоткеи для копирования/вставки по-человечески работают и выделение текста не прямоугольником!

С другой стороны, экосистема тоже становится более дружелюбной к Windows. Например, во многих CI теперь есть возможность запускать свои тесты на машине с Windows. В стандартной библиотеке Python тоже появляются абстракции, помогающие всё меньше думать о разницах между ОС — например, pathlib. Все уважающие себя библиотеки с нативным кодом специально заранее компилируют себя и упаковываются в колёса, чтобы не пугать пользователей Windows ошибками в стиле "C++ compiler not found". Хотя даже для других ОС это делается далеко не всегда.

Нет, я отнюдь не являюсь фанатом Windows, но она с каждым годом воспринимается всё менее враждебно. Уже какое-то время я успешно существую в Windows, решая свои небольшие программистские задачки. Иногда случается какой-нибудь затык, и я снова на время перезагружаюсь в свою любимую Fedora Linux — там проще, но там тоже далеко не всё идеально.

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

https://www.feoh.org/2021-the-year-windows-became-a-first-class-python-development-environment.html

#потоксознания

Хотел бы сегодня затронуть такую важную, но несправедливо игнорируемую тему, как ревьювер экспириенс (RX).

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

Следите за простой арифметикой. Допустим, вы полностью переписываете какой-то метод из N строк. В диффе получится N удалений и N добавлений, итого — 2 * N.

class Example:
- def method(self, arg1):
- return 1
+ def method(self, arg2):
+ return 2

Это много. Это может спугнуть ревьювера, и он просто не откроет ваш пулл-реквест, поэтому лучше так не делать. Есть до безобразия гениальное решение — просто напишите новый код метода ниже, и он заменит собой старый! Код работает точно так же, тесты выдают красивую зеленую галочку, а дифф сократился в два раза, потому что больше нет удалений!

class Example:
def method(self, arg1):
return 1
+ def method(self, arg2):
+ return 2

Аналогично можно поступать и с классами целиком, и даже с целыми файлами. Если же вам нужно избавиться от класса, метода или функции, то можно использовать волшебное слово del, и тогда в диффе вообще окажется только одна строчка:

class Example:
def method(self):
...
+ del method

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

import requests, psycopg2; session, number, connection, matrix = requests.Session(), 5, psycopg2.connect("postgresql://localhost/dbname"), [[1, 2], [3, 4]]
for _ in range(5): print("Hello!")

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

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

Пользуйтесь этими лайфхаками на радость вашим коллегам! Желаю, чтобы ваши пулл-реквесты-многотысячники всегда быстро и без единого вопроса собирали нужные аппрувы! ✊

#секретымастерства

Из предыдущего поста всерьёз нужно воспринять лишь часть про важность подготовки. Остальное всё фарс и сатира, конечно.

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

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

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

О, круть, калькулятор, который умеет запускать питон

https://education.ti.com/en/products/calculators/graphing-calculators/ti-84-plus-ce-python

А вот и стало известно, что одна из вакансий от PSF закрыта, и не абы кем. Теперь Łukasz Langa фулл-тайм работает над развитием CPython как Developer-in-Residence. Напомню, он ещё в качестве волонтера был менеджером нескольких последних релизов и написал несколько PEP, так что судя по всему он отлично подходит на эту роль. А ещё является автором автоформаттера black и пишет прикольную музыку.

Круто работать над любимым проектом. Лучше может быть только когда тебе за это ещё и платят 😅

https://lukasz.langa.pl/a072a74b-19d7-41ff-a294-e6b1319fdb6e/

Вышел последний бета-релиз Python 3.10. Считайте, что это 3.10.-1. Дальше будет как обычно пара RC-релизов в августе и сентябре, и настоящий релиз релиз в октябре.

Уже предвкушаю паттерн-матчинги, торчащие отовсюду 😅

Рейтинг веб-фреймворков на Python, составленный с учётом множества параметров — количество скачиваний, звёзды на GitHub, вопросы на StackOverflow, и так далее. Автоматически обновляется.

https://github.com/tbicr/web-framework-rank#