I often find myself writing a context manager to temporarily change the current working directory:

import os
from contexlib import contextmanager

@contextmanager
def enter_dir(path):
  old_path = os.getcwd()
  os.chdir(path)
  try:
    yield
  finally:
    os.chdir(old_path)

Since Python 3.11, a context manager with the same behavior is available as contextlib.chdir:

import os
from contextlib import chdir

print('before:', os.getcwd())
# before: /home/gram
with chdir('/'):
  print('inside:', os.getcwd())
  # inside: /
print('after:', os.getcwd())
# after: /home/gram

Большое интервью Гвидо ван Россума час назад вышло у Лекса Фридмана

https://www.youtube.com/watch?v=-DVyjdw4t9I

0:00 - Introduction
0:48 - CPython
6:01 - Code readability
10:22 - Indentation
26:58 - Bugs
38:26 - Programming fads
53:37 - Speed of Python 3.11
1:18:31 - Type hinting
1:23:49 - mypy
1:29:05 - TypeScript vs JavaScript
1:45:05 - Best IDE for Python
1:55:05 - Parallelism
2:12:58 - Global Interpreter Lock (GIL)
2:22:36 - Python 4.0
2:34:53 - Machine learning
2:44:35 - Benevolent Dictator for Life (BDFL)
2:56:11 - Advice for beginners
3:02:43 - GitHub Copilot
3:06:10 - Future of Python

#IT #Python

Я всё чаще и чаще замечаю Rust рядом с Python...

Совершенно недавно я нашел вот такой HTTP сервер на Rust для приложений на Python - Granian.

Разработчики ставят перед собой следующие цели:
+ Поддержка HTTP версий 1, 2 и 3
+ Один пакет для всех платформ
+ Сервер должен заменить Gunicorn/Uvicorn
+ Обеспечение большей производительности по сравнению с конкурентами.

Сейчас оно умеет в:
+ ASGI/3 и RSGI
+ HTTP/1 и HTTP/2
+ Вебсокеты над HTTP/1 и HTTP/2
+ Поддержка SSL

К сожалению проект пока что в супер-бетке, поддерживает Питон 3.7/3.8. Очень надеюсь что с этого что-то вырастет.

#библиотека

The typing.assert_type function (added in Python 3.11) does nothing in runtime as most of the stuff from the typing module. However, if the type of the first argument doesn't match the type provided as the second argument, the type checker will return an error. It can be useful to write simple "tests" for your library to ensure it is well annotated.

For example, you have a library that defines a lot of decorators, like this:

from typing import Callable, TypeVar

C = TypeVar('C', bound=Callable)

def good_dec(f: C) -> C:
    return f

def bad_dec(f) -> Callable:
    return f

We want to be 100% sure that all decorators preserve the original type of decorated function. So, let's write a test for it:

from typing import Callable, assert_type

@good_dec
def f1(a: int) -> str: ...

@bad_dec
def f2(a: int) -> str: ...

assert_type(f1, Callable[[int], str])  # ok
assert_type(f2, Callable[[int], str])  # not ok

Смотрите какая штука. Умеет делать hot reloading для многих программ без потери состояния. То есть прям сохраняешь файл на диске, она догружает изменения прямо в работающую программу, что-то там до/перевычисляет до точки останова, и показывает тебе новый результат.

Можно использовать утилиту саму по себе, а можно интегрировать её в редактор. На данный момент есть плагин для PyCharm, а расширение для VSCode в статусе "coming soon". Запилена отдельная поддержка для Django, Flask, SQLAlchemy и Pandas. Вроде можно достаточно гибко управлять поведением reloading'а, чтобы обработать разные краевые случаи.

Выглядит круто!

https://reloadium.io/

P.S. С телефона гифку надо смотреть в оригинале, иначе шакалы.

Python 3.11.1 релизнулся — первая багфикс версия.

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

Кстати, метрика поддержки 3.11 в библиотеках выросла до 25.6%. Месяц назад она была 19.4%.

А слышали ведь про то, что ChatGPT умеет прикидываться bash’ем и успешно интерпретирует разные команды над файлами, запоминая при этом состояние? Похоже, эта нейросеть в целом довольно успешно может симулировать различные интерпретаторы. Python REPL тоже может, причем зачастую учитывает даже разные неочевидные детали. Ответы выглядят будто правильные, но не всегда таковыми являются, само собой, так что доверять такому интерпретатору нельзя.

https://mathspp.com/blog/running-python-inside-chatgpt

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

Список изменений можно почитать в блоге одного из разработчиков: https://ichard26.github.io/blog/2022/12/black-23.1a1/

#black #formatter

Если хотите попробовать новый стиль уже сейчас, то это приветствуется и делается через установку превью-версии:

python -m pip install black==23.1a1

На одном из рабочих проектов форматирование новой версией завершилось вот с таким результатом, то есть изменилось ~5% файлов:

274 files reformatted, 4738 files left unchanged.

Большая часть изменений — это вырезанная первая пустая строка в определениях функций и классов. Пожалуй, хорошо, что форматтер стал за этим следить, а то эти пустые строки воспринимались как что-то лишнее. Кто, блин, их вообще ставит?

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

def frobnicate() -> ThisIsTrulyUnreasonablyExtremelyLongClassName | list[
    ThisIsTrulyUnreasonablyExtremelyLongClassName
]:
    pass

Научился группировать и делать более осмысленные переносы:

def frobnicate() -> (
ThisIsTrulyUnreasonablyExtremelyLongClassName
| list[ThisIsTrulyUnreasonablyExtremelyLongClassName]
):
pass

#black #formatter

Вышел релиз SQLAlchemy 2.0, получается довольно интересно:

- Полная поддержка типов: ORM-модели теперь можно делать полностью типизированные, результаты запросов тоже типизированы
- Теперь ORM-модели можно объявлять как MappedAsDataclass и в этом случае на выходе получатся полноценные датаклассы
- Для массовых добавлений/изменений вместо bulk_* методов теперь можно использовать insert-ы и update-ы, которые стали достаточно умными, чтобы делать это одним запросом и поддерживать .returning()
- C-расширения переписали на Cython и обещают повышение их производительности
- Поддержка нового psycopg3 (aka "просто psycopg")

Резюмируя - очень здорово, что в довольно "олдскульный" SQLAlchemy затащили поддержку всяких современных фич языка. Будет интересно попробовать это все.

Статья про изменения в 2.0 https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html
QuickStart, в котором показан новый подход к объявлению моделей https://docs.sqlalchemy.org/en/20/orm/quickstart.html

В Python 3.12 планируют переделать f-строки в рамках PEP 701 – Syntactic formalization of f-strings.

Дело в том, что f-строки в язык занесли в версии 3.6, когда балом правил еще старый LL(1) парсер, который было сложно расширять, поэтому для f-строк был написан отдельный маленький парсер. Из-за этого они получились слегка неполноценными, а еще в этом отдельном парсере, само собой, были отдельные новые баги. Самое яркое ограничение — это то, что внутри f-строк нельзя использовать те же кавычки, в которых лежит сама строка. Это ж капец как неудобно, что приходится другие кавычки использовать, чтобы просто достать что-то из словаря. У меня линтер на это ругается, и приходится ему каждый раз объяснять, что тут красиво никак не сделать.

Вот, в 3.12 разбор f-строк доверят основному PEG-парсеру, а сам синтаксис f-строк станет частью грамматики языка. Можно будет использовать любые кавычки, которые нравятся. А еще бесконечно вложенные f-строки. Не знаю, зачем нам это, но хорошо, что станет можно. Жду 3.12.

Вышел MyPy 1.0.0, из интересных изменений:

- На 40% быстрее, я очень рад, потому что на более-менее большой кодовой базе он раньше тормозил как не в себя
- Добавили сообщения о undefined variables, использовании переменной до ее объявления. Кажется, тот же flake8 нормально это отлавливает, но все равно выглядит небесполезно
- Добавили поддержку типа Self (есть в 3.11, для более ранних версий надо использовать typing_extensions)
- Реализовали поддержку ParamSpec, но я если честно еще ни разу ParamSpec не использовал в реальном коде, но если интересно, это PEP 612

И еще из интересного, они на конец перешли на semver и теперь будет проще по номерам версий понимать, будут ли подводные камни при обновлении 🙂

Подробнее вот тут https://mypy-lang.blogspot.com/2023/02/mypy-10-released.html

Ещё про изменения в Python 3.12. Недавно приняли PEP 698 – Override Decorator for Static Typing.

Идея простая. Часто в коде переопределяются методы родительских классов, но происходит это сейчас неявно. То есть когда всё хорошо, то тайп-чекер видит, что у родителя есть метод Parent.foo(), у ребёнка есть метод Child.foo(), они называются одинаково, а значит один переопределяет другого. Но вот когда что-то начинает меняться (например, Parent.foo() переименовывается или удаляется, а Child.foo() почему-то остаётся нетронутым), то для тайп-чекера уже не очевидно, что эти два метода как-то были между собой связаны. К сожалению, тайп-чекер видит только нынешнее состояние кодовой базы и не знает с какой стороны мы в это состояние пришли. Короче, есть риск выполнить рефакторинг наполовину, потеряв связи между родителями и детьми, из-за чего много чего может пойти не так, а тайп-чекер просто не увидит проблемы.

В PEP 698 добавляется декоратор @typing.override, который показывает, что отмеченный метод класса является переопределением одноимённого метода родителя. Если у родителя нет такого метода, то тайп-чекер заметит ошибку — хотели что-то переопределить, но только вот непонятно что. Придётся идти и чинить, приводить код в согласованное состояние.

Использование декоратора позволяет тайп-чекеру глубже понимать намерения в коде и вводить дополнительные проверки, но это всё дело добровольное. Без декоратора всё будет работать как прежде. В рантайме декоратор по традиции ни на что не влияет.

Примечательно, что авторы инициативы все из Фейсбука, и пробную имплементацию они тоже занесли в свой фейсбучный тайп-чекер pyre. Похоже, у них там наболело.

Про ruff (1/5)

Несколько месяцев назад:
Что за ruff вообще такой? Линтер? Вижу ридми, обильно приправленный шильдиками и эмодзи, какие-то взрывающие мозг ⚡️бенчмарки⚡️, светло-коричневая полосочка на гитхабе, слышу рёв легионов воинов-фанатиков из твиттера. Погодите, да это же... Да, я определённо такое уже видел. Так происходит каждый раз, когда адепт Rust 🦀 отвлекается на минуту от разбрасывания какашек в комментах про новости о любом другом ЯП и садится что-нибудь переписывать. Это старо как мир. Вот хоть раз это переписанное смогло заменить оригинал? Да, здорово, что есть классные сияющие bat и ripgrep, но всё равно ведь все пользуются дефолтными cat и grep, которые ещё каменным молотом на перфокарте выбивали. Нафига мне переписанный клон линтера, если у меня есть оригинал и он хорошо справляется со своей работой? Да и наверняка, оно неюзабельное и вообще все просто похайпят и забудут через месяц, как обычно. Да и переписали, конечно, не точь-в-точь, а с какой-нибудь неочевидной разницей. Мне вот оно надо в этом разбираться? У меня работы полно. Ага, ну вот, плагины не поддерживаются. Какой может быть нормальный линтер без плагинов? Здорово, что быстрый, но он же нифига не умеет. Короче, это всё информационный шум, пустое.

На прошлой неделе:
Так, чёт много упоминаний. Был недавно на конференции EkbPy, там ruff на слайдах упоминался минимум дважды. Хм, смотрю, прогрессивные FastAPI и pydantic уже выкинули другие линтеры и вкрутили себе ruff в CI. Вижу, TalkPython записали выпуск подкаста про этот тул, а JetBrains собираются записывать про него вебинар прямо в день всех влюбленных. Ого, 8.2к звёздочек на гитхабе — это больше, чем у flake8 и pylint вместе взятых. Репозиторий существует всего полгода, вы вообще когда успели-то? Да даже уже в каналах с мемесами начали про него писать. Да почему все так влюбились в этот линтер? Придётся ставить. Дальше это игнорировать уже нельзя.

И я поставил. Запустил. Блин. А как записаться в легион фанатиков?

Про ruff (2/5)

Если кто ещё не знает, то ruff — это очень быстрый линтер для Python, написанный на Rust.

Давайте начнём разбираться по порядку — сначала про набор правил и про их качество.

С дефолтными настройками ruff повторяет функционал flake8. Вообще, в этом линтере довольно много идей унаследовано именно из flake8, например, настройки очень похожи, названия правил совпадают один к одному. Похоже, ruff позиционируется в первую очередь как замена flake8 — у них даже тулза для миграции есть, которая переносит все настройки.

Но, кроме дефолтных правил flake8, в комплекте уже заимплеменчена куча различных других правил, которые повторяют значительную часть популярных плагинов для flake8, вообще имплементации просто каких-то других инструментов, а также есть немного своих собственных правил. Да, в ruff уже в комплекте есть большинство правил из pylint, есть сортировщик импортов, который фактически заменяет isort, есть mccabe, bandit, pyupgrade. Из того, что я люблю тут есть flake8-bugbear, flake8-pytest-style, flake8-logging-format и другие хорошие плагины. Это всё уже прям встроено внутрь ruff, нужно лишь включить эти правила в конфиге. И да, это всё написано на Rust, как и сам линтер. Автор настолько упоролся, что переписал заново кучу популярных плагинов на другом языке, и он продолжает это делать постоянно. Сейчас у ruff в сумме уже около 400 правил и 44 набора правил. Велика вероятность, что здесь уже есть всё, чем вы пользуетесь. Либо это здесь совсем скоро появится, учитывая скорость развития инструмента.

Я взял большой рабочий проект примерно на 500к строк кода (это много) и запустил на нём flake8 и ruff, предварительно их чуть поднастроив (увеличил длину строки, отключил некоторые правила, которые противоречат black). Результат запуска видно на скрине ниже. Вывод у двух утилит почти идентичен, кроме лишь того, что ruff вставляет в вывод звёздочки [*], про которые я отдельно расскажу чуть позже.

Сумма ошибок слегка не сходится — flake8 находит больше проблем. Предполагаю, что это потому что правило E501 в ruff работает по принципу black, а не строго, как в оригинальном flake8. То есть ruff позволяет слегка выходить за ограничение по длине строки так же, как это делает black. Линтер заточен именно под использование в связке с black. Они даже не стали имплементить большинство проверок, связанных с неправильной расстановкой пробелов, потому что в наш век автоформаттеров эти правила уже не имеют никакого смысла. Этими пробелами в коде всё равно управляет не человек. Ещё ruff потерял несколько ошибок в других правилах, но тут я даже хз. Мне лень искать эти несколько потерянных ошибок среди сотен найденных.

Вердикт: недостатка правил тут точно нет, есть небольшая разница в том, как правила работают. Критична ли эта разница? Для меня скорее нет.