import __hello__

І так всюду і з усім 🙂

Не клікайте

https://neal.fun/stimulation-clicker/

Якщо ви використовуєте pickledb (сподіваюсь що для прототипів, а не для "продакшену"), то для вас новина: її автор випустив вдосконалену версію - kenobiDB, він каже що це більш пропрацьована тред та процес безпечна документна база даних котру він сам використовує у своїх прототипах (а про pickledb він пише "what I now consider very stupid and useless" 🙃).

І якщо ми вже згадали embeded бази даних для пайтону, то щоб два рази не вставати давайте я залишу перелік тих про котрі знаю і котрими користувався (інколи із них дуже зручно почати MVP а потім перемкнути імплементацію на щось "доросле", якщо у цьому буде потреба)

1. montydb

Embeded база даних "яка виглядає і працює як MongoDB". Із документації - лише рідмі у проєкті 😄

>>> from montydb import MontyClient

>>> col = MontyClient(":memory:").db.test
>>> col.insert_many( [{"stock": "A", "qty": 6}, {"stock": "A", "qty": 2}] )
>>> cur = col.find( {"stock": "A", "qty": {"$gt": 4}} )
>>> next(cur)
{'_id': ObjectId('5ad34e537e8dd45d9c61a456'), 'stock': 'A', 'qty': 6}

2. tinydb

Проєкт яким надихався montydb - теж embeded, теж документоорієнтовна, вміє бути drop-in заміною монги через екстеншен tinymongo. Навідміну від montydb має документацію та більшу кількість підтримки на гітхабі (зірочки, коміти, котрибутори)

>>> from tinydb import TinyDB, Query
>>> db = TinyDB('/path/to/db.json')
>>> db.insert({'int': 1, 'char': 'a'})
>>> db.insert({'int': 1, 'char': 'b'})

3. mongita

Mongita is to MongoDB as SQLite is to SQL. Ще одна ліба котра намагається бути заміною монги, але останній коміт у репі був аж 2 роки тому.

>>> from mongita import MongitaClientDisk
>>> client = MongitaClientDisk()
>>> hello_world_db = client.hello_world_db
>>> mongoose_collection = hello_world_db.mongoose_collection
>>> mongoose_collection.insert_many([{'name': 'Meercat', 'does_not_eat': 'Snakes'},
                                     {'name': 'Yellow mongoose', 'eats': 'Termites'}])

Лінки:
- https://github.com/patx/kenobi
- https://www.reddit.com/r/Python/comments/1hqvrd6/kenobidb_30_made_public_pickledb_replacement/
- https://github.com/davidlatwe/montydb
- https://github.com/msiemens/tinydb
- https://github.com/scottrogowski/mongita

З НР!🎄

Це перший рік коли я закінчив івент день у день і на всі 50 зірочок. Цього року навіть вдалось підбити декількох знайомих також приймати участь, тому було цікавіше ніж зазвичай.

Мені сподобалось, із плюсів участі у таких івентах можу назвати:
- трохи тримає тебе у "програмерскій формі", якщо немає звички й так протягом року задротити літкод
- дізнаєшся про різні цікаві проблеми і алгоритми із реального життя. Наприклад цьогоріч я дізнався про алгоритм Брона-Кербоша
- а у минулому році дізнався про крутезний блог https://www.redblobgames.com коли шукав інформацію про Дейкстра та A* алгоритми

Із мінусів - коли день не можеш вирішити пазл, а виявляється що у описі не було вказано якоїсь важливої деталі, чи просто текст був по дибільному написан 😄

Коротше прикольний івент, допомагає якось відволіктись та підготуватись до пошуку нової роботи згадати що програмування це не лише перекладання джейсончиків із бази у http-api 😁

Мабуть функції не по 3 рядка писав 😁

Ну що, розпочався черговий Advent of Code - гарний спосіб відволіктись від буденного життя і отримати трохи новорічного настрою.

Цей івент також може стати гарною нагодою вивчити\підтягнути нову мову програмування (чи навіть технологію, бачив пости де чуваки боролись із aoc у Excel). Я хотів aoc2024 вирішувати на Go, але розумію що цього року у мене набагато менше вільного часу ніж минулоріч, тому знову озброюсь пайтоном, бо це для мене найшвидший спосіб вирішувати задачки.

Сьогоднішній день досить легкий, навідміну від 2023 року, тому не має одразу відпугнути нових учасників 😁

Доречі не забувайте заходити на reddit, після того як вирішете задачки дня, за мемами ☺️

Мене завжди дивує що у розмовах про дивацтва JavaScript обовʼзково згадують про те що 0.1 + 0.2 != 0.3, хоча насправді ця "проблема" є не лише у JS, це наслідок того як компʼютер представляє числа із плаваючою точкою.

Така ж ситуація із "дивацтвом" Пайтона коли хтось вперше бачить що all([]) is True і, не розуміючи чому так, відносить це до категорії unexpected behaviour.

Але це буквально 2500-річна філософська дискусія. Античні філософи вважали, що твердження 'всі єдинороги блакитні' має бути хибним, бо єдинорогів не існує, але сучасна логіка стверджує, що це істина, оскільки не існує єдинорогів, які не є блакитними. Python просто слідує сучасній предикатній логіці, але інша точка зору (у нашому випадку що all([]) має бути False як і порожній список) також досить поширена і була загальноприйнятою позицією до останніх кількох сотень років.

Але ми не філософи, ми програмісти, тому краще подивитись на більш практичні приклади:

all([])        # True
any([])        # False
math.prod([])  # 1
sum([])        # 0
max([])        # ValueError! 

Справа у тому що ці функції реалізують концепцію з теорії категорій - моноїд.

Коли ми працюємо зі списками, нам важливо щоб операції над ними працювали передбачувано. Наприклад, якщо у нас є два списки xs та ys, то:

>>> from math import prod
>>> prod(xs + ys) == prod(xs) * prod(ys)
True
>>> sum(xs + ys) == sum(xs) + sum(ys)
True

А тепер цікавий момент - що буде якщо ys буде порожнім списком? Тоді:

prod(xs) == prod(xs + []) == prod(xs) * prod([])

Це рівняння може бути правдивим тільки якщо math.prod([]) == 1! Тобто одиниця тут виступає як нейтральний елемент для множення. У цього навіть є своє імʼя - порожній добуток (empty product).

Те саме і з іншими функціями:
- sum([]) == 0, бо 0 - нейтральний елемент для додавання
- all([]) == True, бо True - нейтральний елемент для and
- any([]) == False, бо False - нейтральний елемент для or

А от max() такого елемента не має! Не існує такого числа n, для якого max(x, n) == x для будь-якого x. Саме тому max([]) викидає помилку.

Доречі у цього явища є своє імʼя - вакуумна істина (vacuous truth). Це коли вираз вважається істинним, оскільки його умова не має сенсу.

Лінки:
- https://uk.wikipedia.org/wiki/%D0%9C%D0%BE%D0%BD%D0%BE%D1%97%D0%B4
- https://en.wikipedia.org/wiki/Empty_product
- https://en.wikipedia.org/wiki/Vacuous_truth
- https://news.ycombinator.com/item?id=37264149
- https://buttondown.com/hillelwayne/archive/why-any-is-true-prod-is-1-etc

Стаття про фічі нового Python 3.13. Ні, не про noGIL, JIT та інше, а про зміни які ви скоріш за все оминули увагою

https://www.bitecode.dev/p/python-313-what-didnt-make-the-headlines

Якось випадково натрапив на відос "Why don't Americans use electric kettles?" (ютуб рекомендації іноді підкидають щось неочікуване) і залип.
Саме так виглядав би ютуб канал гіка з 60х 😁. Автор бере якусь стару технологію і розповідає про неї так нібито це щойно презентований айфон чи макбук "The Antique Toaster that's Better than Yours"

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

Лінки:
- https://www.youtube.com/@TechnologyConnections

Мені подобається у якому напрямку рухається розвиток Python зараз.
Як на мене, нагальної потреби у додаванні нових фічей у мову зараз немає - вона вже досить давно є зрілою і містить достатню кількість мовних фічей (деякі із котрих можливо треба б було задепрекейтити і видалити)
І те що вже декілька версій у пайтон не додається багато нових можливостей (маю на увазі різний синтаксичний цукор) а навпаки core-розробники сконцентрували свою уваги над поліруванням того що є (покращують REPL, роблять повідомлення про помилки більш інформативними, видалять застарілі частини стдлібу, тощо) та над прискоренням CPython (nogil, JIT, subinterpreters, та звичайні оптимізації) як на мене дуже гарний знак того що у мови буде ще багато років планомірного розвитку.

Ось і новий реліз йде у сторону поліпшення швикодії та покращення developer expirience:

https://www.youtube.com/watch?v=gqqgwyNx52Q

Сьогодні на leetcode.com problem of the day це просто написати якийсь алгоритм сортування, тому ось вам стаття про те як імплементувати найпопулярніші із них із бенчмарками та переліком їх плюсів та мінусів.

Доречі ви знали що саме для Python вигадали новий алгоритм сортування Timsort (отримав назву по імені того хто його вигадав - Тім Пітерс)?
І що на співбесідах його ніхто ніколи не пише, бо для його імплементації спочатку треба написати insertion та merge алгоритми 😁.
Потім цей алгоритм утягнули до себе Swift, V8 та Rust.

Лінки:
- https://realpython.com/sorting-algorithms-python/
- https://en.wikipedia.org/wiki/Timsort

Виявляється що у coverage.py є альтернатива - Slipcover. Це така сама тулза для виміру покриття проєкту тестами але усього із 5% оверхеда у швидкодії (Coveragepy робить виконання вашого коду у три рази повільнішим, для порівняння).
На великих проєктах втричі більш швидкі тести це дуже суттєво.

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

Опублікували відоси із PyCon US 2024

https://www.youtube.com/playlist?list=PL2Uw4_HvXqvYhjub9bw4uDAmNtprgAvlJ

У соурскоді sqlite 😁

За замовчуванням префікс був "sqlite". Але потім Mcafee почала використовувати SQLite у своєму антивірусному продукті, і він почав створювати файли з назвою "sqlite" у папці c:/temp. Це дратувало багатьох користувачів Windows. Ці користувачі шукали в Google "sqlite", знаходили номери телефонів розробників і телефонували їм уночі, щоб поскаржитися. З цієї причини префікс назви за замовчуванням було змінено на "sqlite", написане навпаки. Таким чином, тимчасові файли все ще можна ідентифікувати, але будь-хто, достатньо розумний, щоб зрозуміти код, також, ймовірно, достатньо розумний, щоб знати, що дзвінок розробнику не допоможе позбутися файлу.

Мабуть не відкрию ні для кого Америку, але метадата про кожний пакет у pypi, кількість скачувань і інша інформація доступна у публічному BigQuery.
Тож можна отримати будь яку цікаву для вас інформацію. Ось мені було цікаво знайти нові плагіни для flake8.

SELECT
  name,
  CONCAT('https://pypi.org/project/', name) AS project_url,
  MAX(upload_time) AS most_recent_upload_time
FROM
  `bigquery-public-data.pypi.distribution_metadata`
WHERE
  name LIKE 'flake8-%'
GROUP BY
  name
ORDER BY
  most_recent_upload_time DESC

Звісно ганьба що pypi сам не дає способу нормально шукати по назвам та не показує кількість скачувань пакетів, але маємо що маємо.

Лінки:
- https://packaging.python.org/en/latest/guides/analyzing-pypi-package-downloads/#public-dataset
- https://console.cloud.google.com/bigquery?p=bigquery-public-data&d=pypi&page=dataset

Натрапив на просторах реддіта на репозиторій із переліком штук про котрі треба пам'ятати коли пишеш веб-сервіс на FastAPI.
Їх там зараз небагато, але всі дуже важливі. Мене найбільше зацікавив 9 пункт "Your dependencies may be running on threads" -
це може бути неочевидним, але якщо ваша async def view використовує синхронну залежність (навіть якщо вона нічого не робить а просто повертає примітивне значення)
то резолвінг цієї залежності буде відбуватись у тредпулі.

Тобто ось у цьому прикладі буде використовуватись тредпул незважаючи на те що root view використовує async def:

from fastapi import FastAPI, Depends

app = FastAPI()

def get_42():
    return 42

@app.get("/")
async def root(value: int = Depends(get_42)):
    return {"value": value}

Чим це погано? Тим що треди не резинові і за замовченням одночасно може жити лише 40 тредів, і якшо на ваш ендпоінт буде наплив трафіку, то перші 40 реквестів забʼють
тредпул, а решта буде чекати поки звільниться місце. Звісно що значення по-дефолту можна підняти, але воно всеодно не буде нескінченним.
Виправити у прикладі вище цю проблему просто - замінити def get_42(): на async def get_42(): і тоді всі реквести
будуть запускатись без тредпула, просто у поточному event loop.

Підсумовуючи:
- Завжди у першу чергу використовуйте async def для вьюх (це вже й так всі запамʼятали) і залежностей що інжектяться через Depends.
- Синхронні вьюхи використовуйте лише якщо вони роблять блокуючі операції, наприклад використовують бібліотеку requests для http запитів.
- Перевірте свої додатки - у тому ж пункті є код за допомогою якого можна це зробити

Лінки:
- https://github.com/Kludex/fastapi-tips

Подивився на ютубі інтервʼю з чуваком, який переписав кафку.

⁃ написали все на golang. Сказав, що це мова, до якої немає питань. Типа вони з напарником ніколи її не обговорюють, а просто деліверять фічі;

⁃ в якості стореджа використовується S3. Це дає доволі суттєву економію, порівняно з EBS (що є по суті клаудним NAS на SSD). По суті це реальний cloud native storage, який може скейлитись до нескінченності і має майже 100% SLA. Недоліком є трохи вища latency;

⁃ хочуть повністю повторити протокол kafka, зараз вже все є, крім транзакцій. По суті це drop in replacement для кафки, і існуючі клієнти можуть перемкнутись на їхній сервіс без змін (якщо там немає транзакцій);

⁃ ноги у проекта ростуть з DataDog -- на початку є пара цікавих інсайдів про внутрянку останніх;

⁃ під час написання намагаються не дивитись на код kafka (який на java), натомість використовують код альтернативних клієнтів. Бо протокол дуже складний, мало документований, а в сторонніх клієнтах часто можна знайти коменти про реалізацію підтримки нововведень і різних corner cases

В цілому дуже сподобалось і саме інтервʼю, і проект який вони замутили. Ось посилання, якщо хочете подивитись самі: https://www.youtube.com/watch?v=xgzmxe6cj6A. Крім того, шо я тут написав, там багато цікавого про реалізацію, виклики, що стоять перед подібними системами, мотивацію і тд.

А це власне їхній стартап: https://www.warpstream.com/

Доречі, коли хочеться почати свій пет-проєкт який щось для мене покращить, чи просто just for fun, то треба якнайшвидше приступити до реализації, поки не перегоріло.
Бо поки засетапиш проєкт: додаси лінтери, сконфігуруєш їх, наставиш улюблених плагинів для пайтеста, напишеш Makefile, напишеш workflow для github actions (клятий github actions) - вже пройде декілька днів і бажання щось робити пропаде 😁.
А просто робити щось без цієї автоматизації і собі ж дорожче і не в кайф.

Тому одного разу я зробив собі шаблон для python-проєктів і одразу відчув користь:

- Не треба переносити сетап із минулого проєкту попутньо вирізаючи неактуальні частини конфігів і роблячи перейменування
- При створенні проєкту з шаблону можна робити різні налаштування і включати\виключати потрібні компоненти в новий проєкт. Наприклад якщо планується використовувати pydantic - одразу додати відповідний плагін до mypy
- Так як шаблон це тепер також мій окремий проєкт - він так само як будь який інший проєкт еволюціонує
- Dependabot допомагає слідкувати за актуальністю залежностей у шаблоні

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

Лінки:
- Cookiecutter - менеджер для таких от шаблонів. Не обовʼязково шаблон має бути для пайтона - це може бути шаблон будь чого, навіть не обовʼязково звʼязаний із програмуванням

У Django зʼявляться background workers

Декілька днів тому прийняли DEP-14, наступним кроком буде власне імплементація. Як я зрозумів вони просто зроблять django-tasks частиною Django.
Не те щоб мене ця новина якось обходила, бо я вже давно з Джангою справ не маю (ну майже) але це гарна пропозиція, бо майже будь яка апка на Django трохи більша ніж hello world потребує можливості запускати таски у фоні, а не заставляти юзера чекати її виконання.
Усі для цього використовували Celery, але ця ліба досить велика та потужна і до того не завжи тривіальна у налаштуванні і коли тобі треба зробити лише одну-дві простих дії у бекграунді то тащити цю монструозну лібу не дуже хочеться.
Ну от тепер і не треба буде - у Джанзі і для цього тепер буде рішення "із коробки".