Автоформаттер black принял «политику стабильности». В 2022 ожидайте стабильный релиз.

https://twitter.com/llanga/status/1455496802812239876?s=21

#black

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

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

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

#black #django

АААА! У форматтера black наконец-то вышла стабильная (не бета) версия! Неужели дожили. Я ждал этого тжри года!

https://github.com/psf/black/releases/tag/22.1.0

#black

В Django совсем недавно приняли веру в единый стиль кода и автоматическое форматирование. Пулл-реквест получился царский — около двух тысяч изменённых файлов. Да, Django теперь использует Black!

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

https://github.com/django/django/pull/15387

#django #black

Ещё одна новость про форматирование.

Одна из популярных причин, почему люди не в восторге от идеи внедрить форматтер кода в свои старые проекты — это замусоривание истории изменений. Появляется царь-коммит, который изменяет весь код сразу, и git blame бессилен пробиться через него к более старым изменениям. Получается, с точки зрения Git, человек, запустивший Black, становится автором всего проекта 😅

Начиная с версии 2.23.0 (это 2019 год) Git поддерживает возможность игнорировать некоторые коммиты в git blame, что как раз и решает эту проблему.

Крутая новость в том, что GitHub теперь тоже в своём Blame View научился игнорировать такие коммиты. Создаёте специальный файлик, записываете туда хэши своих коммитов с форматированием кода и вуаля!

https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view

#formatter #github #git #blame #black

Если вдруг кому нужна такая же фича в локальном консольном Git или в GUI, типа PyCharm или VSCode, то вот как это делается:

git config --local blame.ignoreRevsFile .git-blame-ignore-revs

Нужно выполнить после клонирования репозитория. К сожалению, самостоятельно Git находить этот файл пока что не научился.

#formatter #git #blame #black

А если кому нужна такая же фича в веб-интерфейсе BitBucket, то голосуйте за нашего кандидата вот здесь:

https://jira.atlassian.com/browse/BSERV-12730

#git #bitbucket #blame #black

Для GitLab такая фича тоже обсуждается, ставьте свои пальцы вверх вот сюда:

https://gitlab.com/gitlab-org/gitlab/-/issues/31423

#git #gitlab #blame #black

Оказывается, крайний релиз форматтера black 22.1.0 (он же первый не-бета релиз) для всех основных платформ распространяется в виде колёс со скомпилированным нативным кодом. То есть там уже не обычный интерпретируемый питон, а именно нативный код, использующий Python API. На фоне долгожданной стабилизации форматтера эта новость осталась практически незамеченной.

Получается такое через компилятор mypyc, идущий в комплекте с тайп-чекером mypy. Он умеет транспилировать обычный код на питоне с тайп-аннотациями в исходники на C, а их уже можно скомпилировать в библиотеки для большинства платформ.

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

Автор этой инициативы написал серию постов (раз, два, три) про возникшие по пути сложности. Любопытно.

#black #formatter #mypy #mypyc

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

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

#black #formatter