В связи с чем проект Django собирается начать форматировать свой код при помощи black.

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

https://twitter.com/adamchainz/status/1455850491519254531?s=21

#black #django

«Прежде всего, дзен Python говорит, что любое решение должно быть единственное. Поэтому в Python всего минимум по три.»

There should be one-- and preferably only one --obvious way to do it.

А какие ещё вы знаете примеры нарушения этого принципа? Желательно в стандартной библиотеке.

Surprisingly at the top of that curve is again 'no types'

https://twitter.com/fasterthanlime/status/1248025337235210243?s=20

#meme

Всячески рекомендую ютуб-канал "Диджитализируй!". Он периодически снимает классные видео про Python. А сегодня я нашёл там настолько полезное видео, что решил даже запостить его сюда, чтобы в следующий раз, когда беда вдруг снова внезапно меня настигнет, оно было под рукой.

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

#vim

5 ноября вышла вторая альфа Python 3.11 и по мнению людей, которым можно доверять, 3.11 на ~30% быстрее чем 3.10.

В первую очередь рост производительности это работа над идеями по оптимизации в рамках Faster CPython Project. Узнать о новых фичах в 3.11 можно по ссылке.

“Zero-cost” exceptions are implemented. The cost of try statements is almost eliminated when no exception is raised. (Contributed by Mark Shannon in bpo-40222.)

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

#pydaily

Полезный доклад от Андрея Власовских — лида команды PyCharm в JetBrains — про то, как быстрее и умнее редактировать код. В целом, Андрей показывает довольно базовые вещи, которые логично было бы ожидать от IDE. Проблема в том, что многие люди не знают, что их IDE всякое такое умеет, и запускают (относительно) тяжелую среду разработки, чтобы пользоваться ей просто как блокнотом с подсветкой кода. Не надо так, IDE намного умнее. Нужно лишь запомнить один самый главный хоткей — Find Action!

https://youtu.be/FW3_OPBxk2s

#jetbrains #pycharm

Pyjion — проект по скрещиванию ванильного CPython с JIT-компилятором из .NET — получил релиз с круглым номером 1.0.

Напомню:
* по идее этот проект может запускать любой валидный код на Python, включая все библиотеки с нативными модулями (numpy, pandas, psycopg и так далее) без пересборок и каких-либо дополнительных действий;
* работает с самым обычным CPython 3.10;
* работает на Windows, Linux и macOS;
* устанавливается через pip, но будет рассчитывать, что в системе есть компилятор .NET 6;
* всё, что нужно, чтобы магия начала действовать — импортировать pyjion, вызвать pyjion.enable() перед основным кодом программы.

Пока что проект не умеет работать с контекстными менеджерами и async/await. Но это не значит, что он не сможет запустить такой код. Просто JIT-компиляция для функций с такими инструкциями не произойдёт, и они будут работать в обычном интерпретируемом режиме.

Кто-нибудь уже пробовал? Ускорило?

https://www.trypyjion.com/

#pyjion #jit

Попытался разобраться, благодаря чему Python 3.11 уже аж на 30% быстрее 3.10. Собрал небольшой синтетический микробенчмарк с делением чисел. И действительно сразу же видно, что даже на максимально простых примерах без каких-либо исключений 3.11 быстрее примерно на треть. В официальном ченджлоге не упоминается никаких таких оптимизаций, которые могли бы дать подобный эффект. Возможно, документацию пока просто не успели обновить. Возможно, это какой-то побочный эффект от ускорений, связанных с обработкой исключений. Похоже, надо идти в список коммитов в Git и искать ответы там 🤷‍♂️

По поводу "zero cost" exceptions. Разница между кодом вообще без исключений и кодом с блоком try..except, который ничего не ловит, действительно небольшая. Как утверждает официальный FAQ, такие блоки всегда были дешевыми. И в 3.11 эта разница действительно стала ещё меньше — 5 наносекунд против ~2 наносекунд. Тем не менее, цена всё ещё не нулевая. Наверное, именно поэтому автор этой оптимизации ставит кавычки вокруг "zero cost". Если же исключение возникает, то обе версии работают примерно с одинаковой скоростью.

Ссылки:
* детали моего наколеночного бенчмарка;
* идея бенчмарка взята из этого ответа.

Табличка с результатами моего бенчмарка. Видно, что 3.11 в принципе на всех проверенных кейсах работает быстрее.

Вывод: стало быстрее, а почему — я не понял 🤷‍♂️

okay.... https://susam.in/maze/infinitely-nested-dictionary.html

Доказательство Тьюринг-полноты однострочников на Python

#habr #python
#python #ненормальное_программирование #python #тьюринг_полнота #доказательство #написание_кода #плохой_код #ненормальное_программирование #развлечения

Музыкальная пауза!

Смысла в песне никакого (хотя может это я просто не выкупил), но слова знакомые, забавно. Вообще, у этого исполнителя много забавных треков.

Интересный побочный эффект принесло одно из изменений в Python 3.10 — каноничный пример про состояние гонки (race condition) между потоками перестал работать! Операция += (INPLACE_ADD) стала чуть-чуть более атомарной. Полагаться на это поведение, конечно же, нельзя, потому что оно может измениться в любой момент.

https://stackoverflow.com/q/69993959/10650942

PSF заплатите чеканной монетой, чеканной монетой, о-о-о.
Зачтётся все это, зачтётся все это!

Говорят, чтобы поддерживать нынешние инициативы на плаву (developer in residence, packaging), нужно 325 тыс. долларов в год. Чтобы нанять ещё людей, нужно уже 500+. Конечно, спонсоры, типа Google, Microsoft и Bloomberg, здорово выручают и помогают собрать хорошую долю от этой суммы, но всё равно каждая копеечка имеет значение. Python всё-таки community language, так что было бы здорово и обычным рядовым пользователям немного скинуться.

Even if donations are a portion of the PSF's revenue, every dollar makes an impact and allows the PSF financial stability to continue supporting a growing community!

https://www.python.org/psf/donations/2021-q4-drive/

Кстати, в честь этой кампании по сбору средств, JetBrains снова открыли свою акцию — покупаешь PyCharm с хорошей скидкой в 30%, а все собранные средства отправляются прямиком в PSF. Актуально до 1 декабря!

Звучит примерно как «покупайте наш наркотик, а все деньги с вашей первой дозы мы переведём голодающим африканским детям»😅

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

https://lp.jetbrains.com/support-python/

UPD: будьте внимательны, эта акция не применяется для продления уже активных подписок, только для новых!

#jetbrains

В модуле logging предусмотрен немного необычный способ форматирования строки без форматирования.

logging.info('Message %s %s', arg1, arg2)

На самом деле, если вы его не используете то вы делаете неправильно!⚠️

Если вам требуется указать в строке сообщения какой-либо аргумент то обычно это делается форматированием строки

logging.info('New value is %s' % value)

Или любой другой доступный нам способ

logging.info(f'New value is {value}')
logging.info(f'{value=}')

Кажется, всё логично, все так делают. Но нет, это ошибка! 😫

Функция записи сообщения должна быть очень быстрой. Да, она в любом случае занимает время, но чем меньше тем лучше. И особенно, когда это сообщение не проходит по фильтру уровня логирования.
Например, у меня установлен уровень WARNING и выполняется вот такой вызов

logging.debug(f'Current user: {user}')

Что произойдет?
Сообщение не попадает под установленный уровень логирования и будет проигнорировано. Это обрабатывается сразу же первой командой в вызываемой функции debug. Но при этом форматирование строки всё равно произойдёт!
И проблема не в самом форматировании, которое достаточно быстрое (даже при складывании строк через "+"), а в тех возможных действиях, которые придется вызвать для преобразования объекта user в строку.

Возможно, там будет запрос в БД, разбор больших массивов данных или еще что-то не очень быстрое (или не очень умное🤪).
Нам всё это придётся посчитать чтобы потом.....ничего с этим не сделать.

Поэтому правильно писать так:

logging.debug('Current user: %s', user)

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

#libs #tricks

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

Вот такой плагин для flake8 есть: https://github.com/globality-corp/flake8-logging-format

#flake8