И вдогонку чуть более простой и практически применимый материал. Наверное, большинство сейчас для форматирования строк используют f-строки, и чаще всего это просто f"string {variable}", но на самом деле f-строки позволяют удобно форматировать переменную. Например, мне недавно надо было выводить целое число как трехпозиционную строку, т.е. если в числе меньше трех цифр - подставлять в начало нолики (5 -> "005", 10 -> "010", 123 -> 123).

И сегодня наткнулся на pybites хороший гайд по тому, что f-строки умеют. Если вы всем этим богатством не пользовались - очень рекомендую https://pybit.es/articles/python-f-string-codes-i-use-every-day/

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

Начну с короткой заметки, которая хорошо рассказывает о том, какие UUID бывают и для чего их использовать. Если вы всегда просто используете uuid4 то думаю будет полезно расширить кругозор https://www.ntietz.com/blog/til-uses-for-the-different-uuid-versions/

Я последнее время с интересом смотрю в сторону uuid7 - по нему можно делать сортировку и поэтому он выглядит интересно в качестве id-шника. Из коробки модуль uuid в питоне не поддерживает uuid6, uuid7 и uuid8 (потому что пока они по факту не приняты как часть RFC), но есть либа uuid-utils которая реализует все варианты https://github.com/aminalaee/uuid-utils

Вышла Django 5.1, изменений не сильно много, но из интересного:

- поддержка connection pool-ов для psycopg 3
- миддлварь, которая делает аутентификацию обязательной для всех эндпоинтов (полагаю многие писали подобную миддлварьку для своих проектов)
- новый template tag querystring, который позволяет в шаблоне легко добавить новый/заменить значение существующего параметра url-а, сохранив все остальные параметры
- для работы с сессиями пользователя теперь доступно асинхронные методы
- дропнули совместимость с Postgres 12, MariaDB 10.4 и SQLite ниже 3.31.0

ну и много всего по мелочи, почитать release notes можно здесь https://docs.djangoproject.com/en/5.1/releases/5.1/

Вышел новый большой релиз менеджера пакетов uv в котором добавили много нового:

- теперь uv может создавать более сложные файлы зависимостей и самое главное - они теперь кроссплатформенные. Например, если файл создавался, скажем, на маке он будет содержать также хеши для версий пакетов для Linux и Windows и также пакеты, которые нужны только доя конкретной платформы буду указаны и установлены только для нее. Они говорят, что формат файла standart complient но я не совсем понял на какой именно стандарт они тут ссылаются
- появилась возможность ставить нужную версию питона с помощью uv
- появилась возможность запускать с помощью uv другие консольные команды по аналогии с pipx, например uvx ruff check
- возможность запускать скрипты содержащие в файле зависимости (inline script metadata https://packaging.python.org/en/latest/specifications/inline-script-metadata/#inline-script-metadata). При этом он автоматически создаст виртуальное окружение и поставит зависимости туда, а если указанной в зависимостях версии питона нет в система - сам установит ее

В общем выглядит как еще один большой шаг к тому, чтобы заменить другие тулы - https://astral.sh/blog/uv-unified-python-packaging

Хорошая статья про то, как устроена в питоне сборка/установка пакетов и почему именно так. Для тех, кому любопытно чуть больше погрузиться в историю - самое то. Выводы у статьи простые - используйте pyproject.toml везде, где это возможно. Я с автором в этом согласен, например у меня на работе как минимум во всех новых проектах pyproject.toml используется по умолчанию.

Ссылка - https://www.bitecode.dev/p/whats-the-deal-with-setuptools-setuppy

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

JetBrains у себя в блоге опубликовали список идей для проектов на Django. Хотя там в основном высокоуровневое описание проекта без деталей и всего пара ссылок на туториалы, если вам такое актуально - посмотрите https://blog.jetbrains.com/pycharm/2024/09/django-project-ideas/

Зарелизился python 3.13, кратенько перечислю самое интересное, а подробно обсудим на подкасте в первых числах ноября.

Сначала самые интересные штуки, которые пока недоступны конечным пользователям:

- Первый релиз с nogil (который теперь официально называется free-threaded). Доступен только если собрать интерпретатор со специальным ключом --disable-gil, но если очень хочется поиграться, то можно поставить 3.13.0rc3t с помощью pyenv. Производительность пока замерять рановато, потому что сам по себе питон в free-threaded режиме на 20% медленнее обычного из-за проблем с garbage collector-ом, мы с Никитой Соболевым довольно подробно в подкасте про это говорили, в 3.14 должны поправить, а для тестирования совместимости с библиотеками это пока не важно.

- Новый copy-and-patch JIT-компилятор, который (сюрприз!) тоже по умолчанию выключен и требует сборки с ключом --enable-experimental-jit. На самом деле если его включить, то какой-то пользы для себя вы не увидите, так как для работы ему требуются "шаблоны", которые будут заменять куски байт-кода на машинный код, а их еще требуется написать. Собственно, его, как и nogil включили в релиз для того, чтобы можно было экспериментировать

Это все выглядит очень интересно, но давайте перейдем к изменениям, которые можно пощупать и которые реально полезны:

- Эксепшены в питоне, итак, были довольно дружелюбны (по сравнению с другими языками), но в последних версиях идет планомерная работа по их улучшению. В этот раз добавили выделение цветом в терминале и более понятное сообщение об ошибке в случае, когда в проекте есть файл, совпадающий по названию с модулем, который ты хочешь импортировать (пример - у меня в проекте есть файл django.py и я в другом файле пробую импортировать что-то из реальной джанги `from django import forms`)

- Новый клевый repl с подсветкой, возможностью редактировать не только текущую строку, автоотступами, режимами просмотра истории (F2) и вставки (F3) и самое главное – с возможностью писать exit без скобочек 🙂

- Новые улучшения системы типов - дефолты (теперь не надо писать Generator[int, None, None] - можно просто Generator[int]`), возможность объявить атрибут TypedDict-а как `ReadOnly и TypeIs для более строгой проверки типов

- glob("**") из pathlib теперь показывает файлы и папки рекурсивно (раньше показывал только папки), привели в соответствие с тем, как это реализовано в большинстве других инструментов, например ls **

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

Python Software Foundation и JetBrains запустили опрос python-разработчиков 2024. Опрос доступен в том числе на русском языке и результаты обещают тоже перевести. В этом году они хотят охватить больше народа, поэтому если у вас есть 10 минут свободного времени - заполните его. Я уже заполнил 🙂 https://pyfound.blogspot.com/2024/10/join-python-developers-survey-2024.html

Сейчас регулярно вижу (и иногда сам участвую) в дискуссиях "зачем нам nogil"? И вот люди начинают пробовать free-treading билд питона и рассказывают о своем опыте.

Например, вот тут чувак в асинхронной программе вынес cpu-bound задачку в тред используя asyncio.to_thread и предсказуемо получил хорошее ускорение по сравнению с GIL-версией. Конкретно в его случае - в 3 раза.

Пока это просто прикольный эксперимент и вся эта новая машинерия довольно далека от продакшен использования, но лично мне - интересно 🙂 Вполне вероятно, что после полноценного прихода free-terading мы именно так и будем структурировать наш код в каком-нибудь FastAPI - в вебе, конечно, поменьше cpu-bound задачек, по сравнению с datasience, но тоже хватает.

https://blog.changs.co.uk/free-threaded-python-with-asyncio.html

Очень рекомендую канал Никиты, там такого много:)

`LOAD_CONST` разделили на три опкода в 3.14

https://github.com/python/cpython/pull/125972

В Python 3.14 распилили один из самых популярных опкодов: LOAD_CONST. Он, как можно понять из названия, он загружал константы из frame->co_consts:

// 3.13:
pure inst(LOAD_CONST, (-- value)) {
    value = GETITEM(FRAME_CO_CONSTS, oparg);
    Py_INCREF(value);
}

>>> def func():
...     return 1

>>> func.__code__.co_consts
(None, 1)

Теперь LOAD_CONST разделен на:
- LOAD_SMALL_INT для интов в range(256)
- LOAD_CONST_IMMORTAL для загрузки бесмертных объектов (на 1 Py_INCREF меньше, см PyStackRef_FromPyObjectNew vs `PyStackRef_FromPyObjectImmortal`)
- LOAD_CONST для оставшихся

А еще и RETURN_CONST удалили под шумок.

И вот демо байткода:

>>> import dis
>>> def func():
...     x = 1
...     y = ...
...     z = 'привет, мир'

>>> dis.dis(func, adaptive=True)
  2           LOAD_SMALL_INT           1
              STORE_FAST               0 (x)

  3           LOAD_CONST               1 (Ellipsis)
              STORE_FAST               1 (y)

  4           LOAD_CONST               2 ('привет, мир')
              STORE_FAST               2 (z)
              LOAD_CONST               0 (None)
              RETURN_VALUE

>>> # Create caches for tier1 adaptive interpreter to work:
>>> for _ in range(100):
...     func()
>>> dis.dis(func, adaptive=True)
  2           LOAD_SMALL_INT           1
              STORE_FAST               0 (x)

  3           LOAD_CONST_IMMORTAL      1 (Ellipsis)
              STORE_FAST               1 (y)

  4           LOAD_CONST               2 ('привет, мир')
              STORE_FAST               2 (z)
              LOAD_CONST_IMMORTAL      0 (None)
              RETURN_VALUE

Зачем нужен LOAD_SMALL_INT?

https://github.com/python/cpython/issues/101291

Если вы внимательно смотрели мой видос про int, то вы помните, как выглядят инты внутри питона:

typedef struct _PyLongValue {
    uintptr_t lv_tag; /* Number of digits, sign and flags */
    digit ob_digit[1];
} _PyLongValue;

struct _longobject {
    PyObject_HEAD
    _PyLongValue long_value;
};

Большие и сложные объекты. Но, для очень частых маленьких чисел, такое переусложнение замедляет работу. Мы можем просто представлять числа в рамках одного машинного слова и складывать их сразу в oparg, без необходимости заргужать их из co_consts:

op(_LOAD_SMALL_INT, (-- value)) {
    PyObject *val = PyLong_FromLong(this_instr->oparg);
    value = sym_new_const(ctx, val);
}

В Python2, кстати, работало быстрее, потому что там был честный int тип.

Обсуждение

Задумываетесь ли вы про подобные микро-оптимизации, когда пишите код?

Мигель Гринберг, известный своим мега-туториалом по Flask написал большой пост про обработку ошибок в python. Вопросы "когда и какие эксепшены обрабатывать" и "откуда мне узнать, какие эксепшены тут могут возникнуть" особенно актуальны у новичков, я даже у мидлов видел с этим затруднения. Статья довольно длинная, но я очень рекомендую потратить время и почитать https://blog.miguelgrinberg.com/post/the-ultimate-guide-to-error-handling-in-python

Оказывается, на хабре опубликовали перевод статьи https://habr.com/ru/articles/853056/