import __hello__

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

До появи ангулярів, реактів та вью сайтики робили на шаблонах. У Джанзі був (і зараз є) свій движок шаблонів, була 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

А ви ж вже бачили 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. а про те що у стдлібі пайтону є модуль для діфів знали? 🤓

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

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

Так ось, 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

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 котрий поки ніякого пришвидшення не приніс, але у розробників є ще майже рік, тому здається що в них все має вийти.

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

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

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

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

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

Channel created