Любой пхпшник знает, что топовая IDE это джетбрейнсовский phpstorm. Сорри любители Vim с LSP, но это горькая правда🥲 И недавнее исследование от джетбрейнс 🤡 это подтверждает. Кстати, ставьте лоис, если хотите обзор на возможности сторонней lsp (phpactor) для пхп. Или не ставьте. Как хотите, кароч, я все равно сделаю.

Но сегодняшний пост не о восхвалении пхпшторма, а скорее наоборот. Ядром любой IDE я считаю вот эту часть, связанную с lsp и статическим анализом кода. Все остальное - это просто приятные присрачки, без которых жить сложно, но можно. Без стат анализа же ide превращается в обычный блокнот.

Проблема в том, что я уже несколько раз натыкался на баги, связанные с некорректным анализом кода. И тут вы мне скажете "да ты охуел! у всех есть баги!" Но прикол в том, что эти баги не вчера зарепортили люди. И создается впечатление, что никто их не торопится фиксить. Например, как вам вот такой баг из 2023 года. Если вкратце, то в этом коде

$a = ['a'];
$b = ['b'];
$c = [...$a, ...$b];

шторм будет считать, что у $c тип string[][], хотя должно быть string[]. Это в дальнейшнем приводит к false-positive ошибке в редакторе, что очень бесит. И вот в конце 2025го я вынужден использовать array_merge при работе со списками😡

Поэтому я решил проверить свое ощущение и узнать, а как вообще у джетбрейнс обстоит дело с фиксом багов, которые им пользователи приносят. Благо, что у них вполне себе открытые release notes и трекер. В youtrack надо поставить фильтр Subsystem: PHP Inspections, чтоб получить тикеты связанные с анализом пхп. Вот для 2023 года (178 штук), а вот для 2022 (286 штук).

Чекнул релиз ноуты за 2025 год. На момент написания поста, актуальная версия 2025.2.4. Получилось, что в этом году они не исправили ни одной проблемы из 2023 года, исправили 1 тикет из 2021 и 1 тикет из 2022. Это было все в одном релизе 2025.2. И это довольно печально😢

Конечно я не продакт в джетбрейнс, и не мне приоритеты выставлять, чем занять разрабов завтра. Но как минимум мне кажется странным, что почти все тикеты имеют приоритет Normal (процентов 90), либо Nice to have. И только два (тикета, а не процента) имеют приоритет Major. Но, сука, и их никто не торопится фиксить 🤡

Мне странно видеть у всех багов пользователей приоритет Normal. Баги же разные бывают. Некоторые чисто косметические и на них можно забить, а некоторые куда серьезнее. Например, вот этот тикет влияет на возможности рефакторинга. Люди в комментах бампают его, но как-то всем насрать. Проприетарная безысходность...

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

Вот такая осенняя грустняшка сегодня😰

Литералли мой гитхаб

Сегодня жители Санкт-Петербурга могли видеть ярко красное зарево. Это полыхала моя срака после попыток стать pro python девелопером😡

В чем суть. Потребовалось разработать новый сервис. К сожалению его специфика вновь заставила использовать python вместо любимого пхп 😢

Очень часто можно услышать мнение что стандартный пакетный менеджер pip - говно из жопы. Типа он медленный, всратый, не позволяет разделять зависимости на группы, нет лок файла и прочее. Короче говоря, устаревший инструмент. И это не безосновательно.

И вот комьюнити напряглось и родило новый пакетный менеджер uv, который blazingly fast (написан на rust 😍), в котором куча всяких фич, который за тебя готовит виртуальные енвайронменты и прочее. Короче, слышал про него только хорошее.

Подумал, что говорят про него достаточно долго и много, поэтому можно его попробовать затащить в прод. Покурил доку. Вроде бы все выглядит как нормальный пакетный менеджер. Есть pyproject.toml файл, в котором описываются зависимости с требованиями к их версиями, аналог composer.json и package.json. Есть uv.lock, в котором прям точные версии пакетов описываются. Есть команды для установки, удаления, обновления пакетов. Короче, все как мы любим, и все работает реально быстро. Так что же тогда могло так сильно поджарить жепу?

Давайте вспомним, как мы готовим наши проекты для прода. Обычно одним из этапов билда является команда вроде yarn install --frozen-lockfile --production, которая ставит все зависимости из лок файла без development. И вот аналогом такой команды в uv является команда uv sync --frozen --no-dev. Это команда создает venv со всеми зависимостями из лок файла, кроме дев зависимостей.

А дальше вопрос, как запускать наше приложение? Дла этого используется команда uv run. Она сама активирует текущий venv со всеми зависимостями и запустит ваш скрипт. Так, например, рекомендуют запускать uvicorn в докере.

И вот разработчики решили, что будет АХУЕННО крутой идеей при запуске uv run
* проверять, что лок файл соответствует toml, и если нет то обновлять его
* проверять, что venv соответствует лок файлу, и если нет то обновлять venv

Блять, я готов ставить свое сгоревшее очко на то, что когда вы запускаете uv run app.py вы не ожидаете, что у вас че-то будет меняться в лок файле или в venv. Ибо это команда для ЗАПУСКА. Окей, мы поставили все прод зависимости с помощью uv sync --frozen --no-dev, затем выполнили uv run на старте контейнера, и у нас подтянулись все дев зависимости🤡збс! и чтоб этого не случилось, нужно добавлять флаг --no-sync.

И такое "ожидаемое" не только меня сбивает с толку. Считаю, что делать такое было мега тупой идеей. Ибо ни в одном другом пакетном менеджере я не припомню такого поведения. Сук, ты выдай лучше ошибку! Че ты бесиш то! 😡

А так в целом конечно blazingly fast и очень круто 👍

Ну давайте, питонисты, напихайте мне в комментах, что я неправ и команда запуска - отличное место, чтоб обновить venv 😢

Обожаю эту дихтомию синхронного и асинхронного питона. Когда там завезли в питон asyncio? А я вам скажу, когда! async/await - это python 3.5. И это спокойный 2015 год😌То есть 10 лет назад вселенная питона расщепилась на "до" и "после". И вот "после" код в питоне заиграл новыми красками. Во всех смыслах, включая появление т.н. цветных функций.

Казалось бы, 10 лет это приличный срок, чтоб подтянуть всякие библиотеки и сделать возможным использование обоих подходов. Справедливости ради отмечу, что сделано было дохера. И в целом асинхронный питон - это уже давно продакшн реди решниее. Но все равно, то тут, то там вылезают приколы синхронного питона в асинхронном приложении 🐍

Вот и у меня щас немножк вылезло. Собственно пишу я сервис для сбора и экспорта продуктовых метрик в prometheus. Если посмотреть на список официальных SDK, то выяснится, что список ЯП ограничен следующими экземплярами: Go, Java, Python, Ruby, Rust. Поскольку я все таки хочу стать pro python developer'ом, мой выбор был предопределен.

Вот только когда я читал доку по SDK, я че то не заметил, что кастомный коллектор, который мне и нужен, - это синхронный генератор. А у меня асинхронное приложение 🤷

Ну как бы понятно, что это не супер большая проблема. У нас есть целых 3 варианта, как действовать:
* Сделать синхронный кэш метрик, который периодически обновляется асинхронно, а коллектор забирает данные синхронно
* Использовать ThreadPoolExecutor и вынести запросы в бд в отдельный тред прям в коллекторе
* Переписать все на Rust, чтоб было blazingly fast

На самом деле выглядит, как рабочий момент. Придется немношк поприседать. Ничего, бывает. Так что сегодня жопа не горит☺️

А к чему это я вообще говорю. Я на фоне этого всего вспомнил, что в php планируют завезти true async👍 Предвкушаю адский пердолинг на годы вперед, если примут 🤩