Раз в месяц мы в Moscow Python Podcast собираемся и обсуждаем новые релизы, PEP, заинтересовавшие нас инструменты и статьи. В этом выпуске для вас говорили Михаил Корнеев и Илья Лебедев.
Вы также можете посмотреть на нас:
Или послушать на платформах — Apple Podcasts, Google Podcasts, Spotify, Яндекс.Музыка, сайт подкаста
Асинхронный фреймворк Robyn с Rust-рантаймом
В одном из предыдущих выпусков подкаста нам задавали вопрос по поводу будущего Python-фреймворков. Рекомендуем посмотреть на Robin. Он показывает новые веяния в фреймворкостроении на питончике.
Обычно, когда мы запускаем какой-то фреймворк, нам нужен WSGI/ASGI-сервер: Gunicorn, uWSGI или Uvicorn, например. У Robin этого нет. Сразу идет рантайм, написанный на Rust, который реализует WSGI-сервер. С помощью PyO3 он интегрируется с питоном и вызывает питоновские функции. Он делает разбор и роутинг запроса на Rust. И это работает быстрее чем в Python.
Пока Robyn не предназначен для продакшена. Во-первых, в нем нет того, за что мы любим популярные фреймворки: кучи модулей, которые делают практически что угодно, включая совершенно безумные вещи. Во-вторых, в команде сразу нужен будет человек, знающий Rust так же хорошо, как и Python.
Но посмотреть стоит. Детали тут.
PEP 703
Речь про возможность скомпилировать Python без GIL. Необязательный флаг компиляции — кажется разумный способ затащить GIL-версию, живущую отдельно, внутрь основной кодовой базы. И начать потихоньку с ней жить. От введения этого PEP, если его примут, до реального отказа от GIL еще сто верст лесом.
Однако, это решение даст потрогать noGIL версию Python тем, кому актуально. Это как минимум авторы библиотек. Они смогут собрать для себя версию без GIL и посмотреть, как оно вообще работает. Обычному разработчику от этого пока ни горячо, ни холодно. Те же юзкейсы в PEP описывают в основном проблемы датасаентистов. Почитать можно тут.
Релиз SQLAlchemy 2.0
«Алхимия» издревле была известна двумя вещами:
Это что-то для олдов.
А ее документацию как будто написали инопланетяне, и только потом кто-то перевел на английский.
И тут такая новость. Во-первых, документацию переписали и она стала лучше (но впереди все равно еще большой путь). А в-главных, в Алхимии 2.0 куча новинок. Правда, коллеги рассказывают, что мигрировать на нее довольно болезненно. Много чего придется переписывать.
А в остальном, прикиньте, data-классы в SQLAlchemy! Жаль, aiopg еще не поддерживается. Но будем надеяться, что вскоре нужный пул реквест будет вмержен.
PEP 701
Думаю, многие сталкивались с тем, что внутри f-строки не получается впихнуть все необходимое. Теперь f-строки предлагают доработать, чтобы они жрали буквально все.
Это прекрасный пример странной фичи. Для чего нужны f-строки? У тебя есть словарик и ты хочешь вывести: Hello, {first name}{last name}! По ключу вытащил last name, first name и был таков. В худшем случае, какой-то метод вызвал. А тут что? Люди начнут в f-строки запихивать все подряд, если им это позволить.
Когда в f-строки пытаются запихнуть какое-то выражение, читать его становится тяжелее. А читабельность кода важна. Да, с точки зрения полноты языка и возможностей синтаксиса в доработке f-строк есть какое-то количество смысла. Но может быть подумать и над тем, чтобы выводить warning на уровне выполнения кода, если в строке много всего?
Топ-10 библиотек для питониста в 2022 году
С 2015 года Tryolabs выпускают списки самых прикольных библиотек для Python. Неочевидно, как их выбирают. Вот очередной список, а вот его лидеры:
1-ое место - Ruff, линтер на Rust
2-ое место - python-benedict. Позволяет делать safe extraction. Не всегда очевидно, где и для чего применить. Но выглядит забавно.
3-е место - Memray. Это memory профайлинг, очень умный.
Особенно порадовал Memray. Профилировать память приходится довольно редко. Но когда приходится, это не доставляет много радости. Появление еще одной удобной тулы это хорошо.
Короткой сторокой
Два новых эпизода Moscow Python Podcast. В январе мы обсудили взгляд иностранного нанимающего менеджера на российских веб-разработчиков и как работать со звездными разработчиками.
В феврале готовим еще два эпизода:
про Python 3.12 — смотрите нас 10 февраля
про Copilot для Python-разработчика — выйдет в эфир 23 февраля.
PEP 704 — требующий наличия виртуального окружения при установке пакетов. Смотря на то, что происходит с packaging в Python, расстраиваешься. Есть куча PEP, есть куча package-менеджеров и нет понимания, что такое хорошо, а что такое плохо. Вспомнить PEP о dunder packages, предлагавший, чтобы пакеты ставились а-ля mode models. Его типа приняли. Но есть только один или два package-менеджера, которые это поддерживают. И для чего это?
Malware в nightly-билдах Pytorch — если кто-то использует nightly-билды на проде, то кажется он сам выиноват. А в целом - не забывайте пинить зависимости и хэши, всегда проверяйте, тот ли пакет, который нужно вы ставите.
Python 2.7 убрали и из Debian — скоро Python 2.7 останется только в Яндексе. Простите за сарказм.
AnonimYYYs
Насчет f-строк, а какие альернативы? Собирать строку через
print('hello ' + fname + ' ' + sname)? Ну так себе. Черезprint('hello {} {}'.format(fname, sname))? Тоже, имхо, неудобное сишное легаси (при всем моем уважении к си, в котором вроде сейчас тоже уже удобнее есть, хотя тут могу ошибаться).Конечно, тернанрник с тернарником внутрь ф-строки пихать это кощунство, как и какие-нибудь лямбды разрешать, но в целом делать условный
print(f'hello {get_db_fname()} {get_db_sname()}')(с учетом что имена мы не используем где-либо еще и сохранять их в переменные не нужно совсем), так вполне норм подход я считаю.Voldar Автор
Мы скорее о том, что засовывать в f-строки сложные выражения - плохая идея. На мой вкус f'{"\n".join(some_list)}' читается трудновато и я не хотел такое бы в коде видеть
AnonimYYYs
Ну, на мой вкус, за
f'{"\n".join(some_list)}'нужно просто нещадно бить :)А так да, сложные конструкции - выкидывать наружу, типа:
to_print_list = "\n".join(some_list)print(f'some strings: \n{to_print_list}Read them!')
И то, вообще такой подход тоже неверный и ф-строки вообще тут не нужны.
И да, я согласен, что "сложные конструкции" не нужны, но что считать этими самыми "сложными"? Функция с пятью+ переменными? А почему не с четырьмя? А если там будет одна переменная, но длинный словарь, который генерится внутри через for?
В общем, на самом деле, решить эту проблему так, чтобы прям все-все были довольны - сложно на уровне PEP. Намного проще ввести codestyle и уже там описать, например "если внутри скобок в ф-строке более 20 символов - вводить переменную и выносить туда".