Невже для Python нарешті зʼявилась бібліотека для побудови нативних UI.

Завдяки Toga можна робити нативні додатки для WIndows, Macos та Linux (нажаль лише GTK). В ідеалі написав один раз - працює одразу у всіх ОС (але це не точно). Також заявлено про підтримку Andoid та iOS, але я не перевіряв.

Toga - це частина проєкту BeeWare.

Останнім часом намагаюсь знайти більше україномовного IT контенту. Але звісно ж що один у полі не воїн, тому створив awesome list на github - можливо хтось наткнеться та захоче його доповнити, ну або просто буде комусь корисним, мене це теж влаштує.

Python 3.13 буде дуже цікавим. Зокрема через те що 3.12 був нудний. Так вийшло тому що у 3.12 увійшло багато підкапотних штук котрі знадобляться core-девам у наступних релізах для того щоб зробити CPython більш швидким.
Зокрема однією з таких фіч буде JIT, котрий Гвідо обіцяє включити у наступний реліз мови. Доречі ця ініціатива дуже цікава з точки зору підходу до неї, бо чому досі пайтон не мав JIT, хоча здається що більшість мов у яких є інтерпретатор його мають (JavaScript, Java, Ruby, та навіть PHP).
Відповідь на це питання досить прагматична і якщо розуміти ким розроблюється Python то досить логічна.
"Класична" реалізація JIT потребує суттєвого ускладнення реалізації інтерпретатора, тому що потребує написання коду на asm й до того ж, якщо у подальшому будуть виявлятись помилки у інтерпретаторі, то доведеться виправляти їх не лише у С-коді, але й у асемблері. Все вищесказане дуже ускладнює підтримку й розробку CPython, що досить критично для проєкту котрий підтримують практично лише волонтери й у який не вкладаються гроші як у V8 компанією Google.

Добре що буквально минулоріч зʼявилась дослідницька робота "Copy-and-patch compilation: a fast compilation algorithm for high-level languages and bytecode" завдяки котрій можна отримати досить швидкий JIT з мінімальним ускладненям реалізації інтерпретатора (більш зрозумілий пост).
Brandt Bucher вже, за два місяці, зумів зробити робочу імплементацію. Вона має такий вплив на кодову базу CPython:

Build time:
- ~700 строк комплексного Python коду
- ~100 строк комплексного С коду
- LLVM залежність

Run time:
- ~300 строк зрозумілого С коду (написанного програмістом)
- ~3000 строк зрозумілого С коду (згенерованого)
- жодних нових залежностей

Тобто основна складність у реалізації JIT міститься у Python коді, що дуже важливо для підтримки проєкту. Ще дуже важливо що хоча мейнтейнери й додали залежність на LLVM - це build-time залежність, тобто для тих хто встановлює Python нічого не зміниться.
А ще, на відміну від "класичної" реалізації - якщо треба буде виправити баг у інтерпретаторі - його треба буде виправити лише один раз, решту згенерує автоматично LLVM.

Таким чином нова версія Python не стане складнішою у підтримці, але всеодно отримає JIT. Щодо очікуваного пришвидшення поки ніякої інформації немає, бо це лише підготовчі роботи, по суті це baseline JIT котрий поки ніякого пришвидшення не приніс, але у розробників є ще майже рік, тому здається що в них все має вийти.

Тут продублюю лінку на відео з поста Гвідо

Так ось, Python 3.13. У наступній версії ще мають завести API для сабінтерпретаторів. Чому я на це чекаю? Тому що здається це буде той тип мультипроцесінгу котрим вже можна буде користуватись. У кожного сабінтерпретатора свій GIL, тобто ми зможемо паралельно запускати CPU-bound обчислення на декількох ядрах одразу. Ми правда й зараз це можемо робити через модуль multiprocessing але сабінтерпретатори запускаються швидше ніж новий процес (але звісно повільніше ніж новий тред) і судячи з еспериментів Eric Snow мають менше накладних витрат.

Доречі у 3.12 цю фічу вже можна помацати якщо імпортувати модуль _xxsubinterpreters, але біжати писати продакшн код звісно не треба. Зараз виконувати у сабінтерпретаторі можна лише строки (ну тобто працює мийже як eval) і у 3.13 якраз мають доробити апі щоб можна було виконувати функції у окремому інтерпретаторі, а може додадуть й новий екзекутор до concurrent.futures. Взагалі схоже на те що сабінтерпретатори можуть розвиватись як горутини у Golang, бо shared пам'яті у них нема, а дані передавати можна будет через os.pipe, ну тобто напрошується якийсь механизм типу контекста.

Щодо очевидних проблем їх реалізації. Якщо розробники зроблять апі якогось SubInterpreterPool то їм треба буде очищати стейт сабінтерпретатора поміж викликами, бо якщо цього не робити, то те що буде виконуватись у окремому інтерпретаторі не буде детерміністичним, бо результат може залежати від порядку виконання функцій. Мене також турбує, як вирішать питання імпорту модулів. Тобто коли я хочу запустити функцію у сабінтерпретаторі, яка використовує імпортований модуль, як його автоматично імпортувати на старті? Я сподіваюся, що вони знайдуть розумне рішення, оскільки вимога робити імпорти прямо у функції була б зовсім не найкращим варіантом.

Контекст:
- Python 3.12 Preview: Subinterpreters
- Python 3.12 Subinterpreters: A New Era of Concurrency

Доречі ось дуже класний пост по темі. Там і про історію і про порівняння сабінтерпретаторів з тредами, процесами, корутинами, про PEP703, про механізми комунікації і тд.
Ну і вишенкою - запуск web фреймворків у сабінтерпретаторах, з no-gil Python (автор заюзав 3.13 альфа із спеціальним флагом). Із цікавого - Django поки так запустити не вийде, тому що Джанго використовує модуль zoneinfo, бо у модулі datetime у С коді використовується глобальний шейред стейт, але з fastapi та flask вже вийшло погратись.

https://tonybaloney.github.io/posts/sub-interpreter-web-workers.html

А ви ж вже бачили Textual? Це такий фреймворк для написання TUI програм. А я навіть спробував - мені інколи треба дивитись ревізії у CouchDB, але робити це через WEB-морду, чи через API не дуже зручно, а бачити діф між двома ревізіями там взагалі не можна.

Тому я згадав що десь чув про новий модний фреймворк для написання TUI і за пару днів склепав для себе апку. Спочатку щось не дуже добре виходило, але коли я збагнув що треба юзати такий самий підхід як при написанні Vuejs застосунків, то справа пішла значно швидше. Бо як виявилось фішка тут та сама - робиш "тупий компонент" котрий нічого не знає про бізнес-логіку, а шарить лише за відображення, а вже стейтом і логікою рулиш рівнем вище. Звісно якщо б я спочатку прочитав рідмі то одразу б побачив фразу "Textual adds interactivity to Rich with an API inspired by modern web development" яка б мене на ці думки б й наштовхнула, але хто ж ті рідмі читає, правда?

Тож у мене тепер є інструмент для швидкої розробки гарних TUI-апок, за допомогою яких можна трохи підвищити свою продуктивність. Доречі у екосистемі цього фреймворку є тулза для снапшот тестування pytest-textual-snapshot яка дуже непогано працює.

PS. а про те що у стдлібі пайтону є модуль для діфів знали? 🤓

Історія йде по спіралі

До появи ангулярів, реактів та вью сайтики робили на шаблонах. У Джанзі був (і зараз є) свій движок шаблонів, була Jinja, у Ruby on Rails - ERB, у Laravel - Blade. "Фронтенд" писали або самі бекенд розробники, або верстальщики, котрі щось-там розуміли за шаблони. Коли треба був інтерактив, типу кнопочки "Додати в обране" без перезагрузки сторінки - писали скрипти на ванільному JS, але частіш на jquery - робиш запит на бекенд, бекенд там щось опрацьовує, а у відповідь відправляє шматок html, який ти через js вставляєш на сторінку. Але у такому сетапі багато красівостей, котрі хочуть дизайнери, не намалюєш, бо проєкт на jquery, де багацько логіки перетворюється на лапшу зі швидкістю світла. Хоча я на початку свого програмерського шляху працював у фірмі, де ідеєю-фікс було зробити свій продуктовий каталог з фільтрами і пошуком без оновлення сторінок на jquery - воно навіть якось працювало 😄

Потім зʼявились ангуляри з реактами, фронденд розробники стали вже справжніми програмістами, котрі писали свої окремі апки для клієнтів, а дані ганялись по ендпоінтам у json форматі. Осьо воно так працює і досі.

Але зараз звідусіль можна почути, що те, як воно живе, наразі терпіти більш не можна і давайте все писати на htmx. Чули про таке? Ось я у своїй бульбашці про нього чую кожен день на ютубах, редітах, твітерах та подкастах. То що ж воно таке?

htmx - це така js-бібліотека, котра дозволяє викинути на мороз фронтендерів і писати інтерактивні сайтики на шаблонах, як у 2010 році. Ну тобто, тобі взагалі не треба думати про js - просто пишеш hx- атрибути у html, а воно все за тебе саме зробить - сходить на бекенд за шматочком html та вставить його на сторінку. Прикольна штука, фігачиш собі шаблончики, вони чудово кешуються, а дані запрошуються лише за необхідністю. Правда якщо стейкхолдери захочуть якихось космічних фіч на фронтенді, щоб все воно блимало і свистіло тоді доведеться щось вигадувати додаткове. А якщо воно справді масово стрельне? Куди всі фронтендери дінуться? 😅

Доречі, у нас у ua домені є маркетплейс, котрий це використовує, не htmx правда, а свою власну аналогічну лібу TwinSpark - це kasta.ua. Зайдіть, відкрийте консоль розробника та подивіться на дані які ганяються мережею. Між іншим, через такий мінімалістичний підхід PageSpeed показує ~66 поінтів на мобайлі, хоча, якщо викинути усю аналітичну мішуру, то буде мабуть усі 90 😅.

Який висновок? Та хз, просто приємно було згадати про часи коли jquery був кращим і єдиним js фреймворком 😂. Ось вам бонусом, якщо щось зацікавило:
- Як працює TwinSpark
- Twinspark.Morph — оновлення HTML без втрати стану
- інтервью з розробником htmx

Бажаєте прискорити свій Python скрипт до 1000Х не змінюючи жодного рядку коду? Щоправда не будь який, а лише той що використовує Pandas, ну і звісно лише якщо у вас є Nvidia GPU 😁

Matt Harrison твітнув що розробники у Nvidia зробили пакет которий дозволяє Pandas робити обчислення на GPU. Працює це як у Jupyter так і з консолі командою python -m cudf.pandas yourscript.py. Ось такі справи 🙂

Ледь не забув - сьогодні ж перший день Advent of Code

Не впевнений що мого терпіння вистачить на весь місяць, але перший тиждень-два виконувати ці завдання доволі цікаво 🙂

Ліньки мені сьогодні щось писати, тому трохи поділюсь з вами каналами на ютубчику котрі дивлюсь. Але мої смаки специфічні, тому якщо шо - я попередив

anthonywritescode - це канал здебільшого про пайтон, який веде дуже крутий чувак, котрий зараз працює розробником в Sentry
CodeOpinion - тут про всяки архітектурні штучки у форматі коротких відосиків, досить пізнавально
Clear Code - тут мені подобається дивитись 8-годинні відоси про розробку ігор на pygame. Затягує, але не для кожного 😁
DaFluffyPotato - канал фултайм розробника ігор на pygame. Колись я таки перестану прокрастинувати і зроблю свою гру на цьому двіжку)
Coder Space - це скарб, чувак на пітоні витворяє усілякі штуки із графікою, особливо мені сподобалась серія відосів про відтворення DOOM на python 👍
Miziziziz - ще один канал про гейм-девелопмент, але про пайтон там нічого не має. Цікаво дивитись як автор робить різні ігри, бо ідеї для них у нього досить незвичайні
ThePrimeagen - навряд комусь відкрию Америку, але без цього каналу перелік був би не повний. Він працює у Netflix бтв

Хм, майже ніколи не мав необхідності використовувати collections.Counter, а сьогодні і в робочому проєкті заюзав бо воно прям лягало класно і у сьогоднішньому завданні Advent of Code також 🤔

Доречі маю звичку час від часу передивлятись доку стдліба пайтона, чи читати доки ліб котрими найчастіше користуюсь. Трапляється знаходити круті штуки про котрі не знав, чи забув.
Ось один з таких цікавих модулів - graphlib. Додали його нещодавно, у 3.9, я тоді реліз ноутс почитав і одразу ж про нього забув, допоки в черговий раз не поліз передивлятись доку.
Автори Piccolo-orm в захваті від такого доповнення 😁