Заметил, что isort стал работать медленно — 24 секунды на небольшом проекте, что явно многовато. Запускал просто isort .. Решил попробовать так: isort src tests — и вот уже 12 секунд. Странно, ведь ненужные директории указаны в skip

Полез в документацию и узнал пару интересных моментов. Оказывается, в конфиге есть два параметра: skip и extend_skip.
skip полностью заменяет стандартный список исключений и исключает только указанные вами элементы.
extend_skip добавляет дополнительные элементы к существующему списку исключений, не убирая стандартные.

Получается, что когда я добавил skip = ["frontend"], я убрал все стандартные исключения. Что, вероятно, и замедлило работу. Заменил skip на extend_skip, и время уменьшилось до 12 секунд.

Вывод: читайте доки)

Там появился целый сайт, посвященный NoGIL в Python: https://py-free-threading.github.io/
Там есть информация о том, как забацать себе многопоточный питон в 3.13, кое-какая техническая информация и, что интересно, список C-Extension-библиотек, для которых уже заявлена поддержка работы с NoGIL.

Да-да, многие расширения сломаются, так что, не получится просто так взять и перейти на NoGIL-ветку в вашем проекте, увы.

Что особенно интересно, в списке библиотек с поддержкой NoGIL, нету uvloop и pydantic.
Короче, в вэбе все пока тухло.
Но складывается ощущение, что ко всей этой NoGIL движухе подходят ответственно. И на том спасибо.

У вас бывает такое, что, вроде бы все - “ок”, но все равно что-то в жизни не то?
Ну знаете, вроде и работа хорошая и денег хватает. В личной жизни ништяк, не к чему придраться, но все равно есть какое-то неуловимое ощущение, что некуда себя деть...
Нет депрессии, выгорания тоже. Но все равно - “так себе”.
Просто жизнь какая-то тоскливая...

Сейчас снабжу вас новым термином.

Эмоциональное томление.

И лекарство от этого состояния тоже известно. Это - состояние потока. Так называют состояние, когда мы сильно чем-то увлечены и во что-то погружены.

Казалось бы, наше с вами девелоперское ремесло идеально подходит для того, чтобы погрузиться с головой, да?

Считается, что для достижения потока необходимо объединения трех условий.

1️⃣. Нужно постоянно чувствовать свой прогресс
2️⃣. Нужно, чтобы нас никто не отвлекал
3️⃣. Нужно ощущать значимость того, что ты делаешь

Единообразная работа, которая потом еще и будет выброшена в мусор?
Созвон на созвоне и постоянное дерганье в Slack?

Не, не слышал.

У нас все более-менее только с чувством прогресса, так как постоянно разбиваем задачи на подзадачи и можем отметить их выполнение, но это тоже не совсем то. Для себя мы довольно редко растем на работе. А это важно.

Поэтому один из советов для благополучия - иметь хобби.

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

Как?

1️⃣. На мой взгляд, можно, например, выбрать незнакомый язык программирования.
Но такой, чтоб нравился.
Rust, Clojure или, там, Elixir - идеальные кандидаты.

Так мы сможем ощущать прогресс в чем-то новом для себя.

2️⃣. Вырубать мессенджеры.
Серьезно, без этого никак. А если вы, как я, иногда кодите на стриме, то, хотя бы отводить время для чатов и отделять его от времени для кода (у меня с этим, пока, плохо).

3️⃣. Делать то, на что не насрать.
Можно попробовать делать то, что поможет людям. Даже не обязательно, чтобы сам продукт помогал людям. Я люблю транслировать процесс новичкам, чтобы они могли учиться вместе со мной.

Вот так я это вижу. Не претендую на истину в последней инстанции.

Ну и напоследок. По статистике StackOverflow, в 2024 году, только 20% программистов счастливы на своей работе.

Моя идея с потоком явно не решает эту проблему. Это - комплексная тема, которой я хочу касаться в будущем.
Но не повредит - это точно. Да еще и поможет. Выступит в роли одного из кирпичиков в нашей кукухе. Серьезно, надо с этим что-то делать! Мы много зарабатываем, но какой смысл, если мы по итогу менее счастливы, чем фермеры и сантехники?

Ну вот же! Ну еще совсем чуть-чуть и у моего любимого Helix появится система плагинов: https://github.com/helix-editor/helix/pull/8675
По уму, это должно сделать изучение NeoVim с нуля, бесполезным занятием, так как плагины - последнее, в чем он лучше.

Сейчас Helix можно расширять и без плагинов, но это довольно ограниченно. Например, у редактора есть поддержка LSP, а значит, к нему можно прикрутить что угодно, что реализует этот протокол (из примеров - вот этот LSP, добавляющий поддержку Copilot и ограниченно Codeium и ChatGPT)
Или, например, в сети есть инструкции, как, вооружившись философией Unix, приделать к нему сбоку файловый менеджер (не без помощи Tmux).
С появлением полноценных плагинов на Scheme (респект, кстати, за выбор языка), такие извращения станут не нужны.

GitHub

Add Steel as an optional plugin system by mattwparas · Pull Request #8675 · helix-editor/helix

Notes: I still need to rebase up with the latest master changes, however doing so causes some headache with the lock file, so I'll do it after some initial feedback. Also, this depends on the ...

Окей, раскрою тайну.
Несмотря на мою любовь к TUI-инструментам, я сам чаще использую как GUI, так и CLI как для git-а, так и для других целей.
Так-же, мой основной инструмент для написания кода - это PyCharm, как бы скучно и буднично это ни было.
Я люблю Helix, бесконечно уважаю Vim и Emacs, но мне не удается задрочить их до состояния, когда начинается тот самый обещанный буст перформанса.
А моя философия не дает мне дико упороться в инструмент, который даст не так уж много.

На самом деле, PyCharm (и вообще, продукция JetBrains) - это настоящие шедевры.
Да, они жрут дофига оперативы и стартуют не мгновенно, но это и не страшно. Какое совпадение, у меня, как раз, дофига оперативы!

Helix я использую как свой второй инструмент и, несмотря на его великолепие, плотно поглядываю на Micro как на возможную альтернативу.
Причина - большое различие в UX разных инструментов. Когда у тебя один инструмент - модальный редактор, а другой - традиционная IDE-шка, - о формировании мышчной памяти можно забыть.

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

Мой путь - это переназначение клавиш ijkl на стрелочки при нажатом CapsLock.
Заметьте, не hjkl, как в Vim.
Делается это легко разными способами. Раньше я использовал xmodmap. Сейчас - InputRemapper. Это все в Linux. Но под другие операционки аналогичные тулы тоже есть.

Чисто на всякий случай, для будущих поколений:
У меня не сработал запуск сервиса InputRemapper по инструкции из их Github-а. Но все сработало просто такой командой: sudo systemctl enable input\-remapper. Вдруг кому пригодится.

Идея именно такого переназначения клавиш не моя. Я подглядел ее в древнем и ныне заброшенном ЖЖ Никиты Прокопова.

Помимо ijkl, для достижения дзэна, я люблю использовать некоторые дефолтные плюшки PyCharm. Например, на радость Vim-ерам и Helix-ерам, там тоже есть полноценные клавиатурные макросы.
Ну и я писал уже, что работа с мультикурсорами там - просто пушка.
А недостатков легковесных тулов там тоже нет (например, Helix у меня часто не может нормально работать с импортами установленных библиотек. Не видит их из venv-а).

Ну и, наконец, использовать мышь, если тебе вдруг, О УЖАС, пришлось убрать пальцы с клавиатуры - это не так уж плохо.

80% пользы за 20% усилий - мой дивиз по жизни. Так что, PyCharm рулит.

UPD:
Для нормальной работы, надо выключить CapsLock (не велика беда) в настройках системы. Ну мало-ли, вдруг правда кто-то решит этим заняться)))
И да, прямо в InputRemapper надо включить автозагрузку своих пресетов. Для того, чтобы задать клавиши-стрелочки, надо набирать KEY_UP и т.п..

Что сулит нам грядущий Python 3.13 помимо отключения GIL и простенького jit-компилятора?
Признаться, этих двух вещей достаточно, чтобы многие с нетерпением ждали, что из этого выйдет. Но любопытство заставляет меня продолжать мониторить pep-ы. Как минимум, несколько любопытных предложения имеют статус “Accepted” и в графе с версией указан Python 3.13.
Это не гарантирует, что все эти изменения будут реализованы, но в планах они есть.

И вот что я вам скажу... Разработчики Python дохренище внимания уделяют аннотациям типов.

Пример - PEP-649 (https://peps.python.org/pep-0649/) добавляет новое специальное (”дандер”) поле у объектов - __annotations__, которое нужно для ленивого вычисления аннотаций типов. Насколько я могу судить, это поможет инструментам статического анализа. Вроде там в PEP-е написано что-то про то, как реализован механизм, когда мы можем аннотровать поле класса еще не определенным классом (или самим собой). Помните, раньше приходилось писать имя класса в строчке? =D. Видимо, под капотом это будет теперь работать подругому.

Более приземленный и близкий простым работягам - PEP-696 (https://peps.python.org/pep-0696/). И снова про аннотации. Теперь у тайп-параметров есть значения по умолчанию:

```
T = TypeVar("T", default=bool)

class Foo(Generic[T]): ...
```

и с новым синтаксисом джереников:

class Foo[T = bool]: ...

Ну красота-же? ~~Хотя как-то пофиг...~~

Мне больше нравится PEP-702 с пометкой устаревших интерфейсов.
Вот такой pyi-файл:

@overload @deprecated("Only str will be allowed") def foo(x: int) \-> str: ... @overload def foo(x: str) \-> str: ...

Предполагается, что инструмент проверки типов выдаст предупреждение при попытке передать в foo объекта типа int.

Есть PEP-742 (https://peps.python.org/pep-0742/) для того, чтобы писать ... я так понял, свои аналоги функции isinstance ~~, зачем-то,~~ и чтобы тоже все в проверке типов работало...

PEP-705 (https://peps.python.org/pep-0705/) дает TypetDict-у read-only поля...

Имхо, скучно.
Интересно было смотреть за релизами, когда в них появлялись паттер-матчинг или новый синтаксис дженериков! Ух!
А 3.13 - чисто технический релиз. Ощущение, что мы его не особо-то и заметим.
А то, сколько специфичности нарастает на систему статических типов, я начинаю опасаться, что Python станет больше похож на Scala.
Имхо, все хорошо в меру.

Жду разве что - PEP-730 (https://peps.python.org/pep-0730/) и PEP-738 (https://peps.python.org/pep-0738/).
Это - поддержка Python платформ iOS и Android...

Внезапно, однако) В самих PEP-ах упоминаются Kivy, BeeWare и Chaquopy (про последний я вообще в первый раз услышал) со словами, что мол они демонстрируют, что тема рабочая.
А теперь вот будет какой-то движ на эту тему от команды самого языка. Приятно. Надеюсь, это как-то упростит работу над совершенствованием Kivy и, скажем, Flet (за последним я, нынче, пристально слежу).

Такие вот соображения. Что думаете?