Сьогодні на 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

Realpython

Sorting Algorithms in Python – Real Python

In this tutorial, you'll learn all about five different sorting algorithms in Python from both a theoretical and a practical standpoint. You'll also learn several related and important concepts, including Big O notation and recursion.

Опублікували відоси із PyCon US 2024 https://www.youtube.com/playlist?list=PL2Uw4_HvXqvYhjub9bw4uDAmNtprgAvlJ

GitHub

GitHub - nedbat/coveragepy: The code coverage tool for Python

The code coverage tool for Python. Contribute to nedbat/coveragepy development by creating an account on GitHub.

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

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

YouTube

PyCon US 2024

PyCon US 2024 - Pittsburgh, PA

У соурскоді 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/

Добре, поки мене не було я не лише серіали дивився, я також встиг написати ще одну DI бібліотеку для Python ?. Навіщо то взагалі у Пайтоні? Ну сама концепція DI це дуже крута штука, яку можна використовувати будь де без усіляких фреймворків. Але у такому…

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

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

Django Project

Django Enhancement Proposal 14: Background Workers

Posted by Benjamin Balder Bach, Cory Zue, Carlton Gibson on May 29, 2024

Добре, поки мене не було я не лише серіали дивився, я також встиг написати ще одну DI бібліотеку для Python ?.

Навіщо то взагалі у Пайтоні? Ну сама концепція DI це дуже крута штука, яку можна використовувати будь де без усіляких фреймворків. Але у такому разі треба самому бутстрапити залежності при старті апки і думати як оверайдити залежності у тестах. До того ж скоріш за все це все скатиться у service locator та нескінченні if my_service is None: my_service = get_my_service().

Раніше я користувався dependency-injector. Це чудова ліба, але вона завжди здавалась мені дуже навороченою для моїх цілей. І якщо на робочих проєктах її використання ще якось було виправдано, то для маленьких pet-проєктів це точно оверкіл - я завжди починаю з перечитування документації перш ніж засетапити новий проєкт із цією лібою. До того ж вона вже 2 роки не розвивається, тому я почав шукати альтернативи.

Мені подобається концепція DI у FastAPI - залежності це звичайні функції, ніяких контейнерів чи цілої пачки різних типів провайдерів - якщо хочеш щоб твоя залежність була кешованою - просто оберни її у lru_cache.

Із того що я знайшов цікавого у pypi:
- FastDepends - типу як у FastAPI, але із якимись лівими функціями, інколи скаржиться на аргументи які не мають інжектитись через тайп анотації, не має ресурс менеджменту і не може ніяк засунути async залежність у sync функцію, навіть якщо ми вже у async контексті, а ще не дуже дружить із FastAPI ?
- picobox - дуже крута концепція, але функціонал в основному зусереджений на Scopes (щоб залежності кешувались як сінглтон, у треді, у асінк тасці, реквестах, тощо), не має ресурс менеджменту і не дуже дружить із тайп анотаціями
- injector - стара ліба, мабуть непогана, але мені ніколи не подобався її API
- di та rodi - це більше схоже на ресолвери залежностей, над якими ще треба побудувати свій зручний API, хоча я може і помиляюсь

Тобто нічого із того що я знайшов мені не підходить. А мені усього то потрібно:
1. Власне інжекція залежностей у аргументи функцій, було б гарно якби як у FastAPI
2. Менеджмент ресурсів - щоб можна було зробити залежність яка має teardown і кешує свій результат впродовж життя апки - зручно для конекшенів у БД
3. Можливість оверайдити залежності для тестів
4. Зручний API і без зайвих можливостей

Тож я написав picodi (спочатку це мало бути nanodi, але pypi сказав що імʼя дуже схоже на вже існуючу лібу і не дав створити із такою назвою)- по суті це декоратор котрий резолвить (просто викликає функцію) залежності і сує їх у декоровану функцію, усе. Із додаткових можливостей - ресурс менеджмент, оверайдинг залежностей, працює із FastAPI і бонус - можливість резолвити асинхронну залежність-ресурс у синхронну функцію і ніякого вайрінгу (і ніякого детекту циклічних залежностей також ?). Можливо імплементація трохи наївна, але поки мені подобається - я вже замінив dependency-injector на декількох своїх pet-проєктах без якихось проблем.

Тож якщо у когось з вас є схожі вимоги до DI фреймворку - можете спробувати, та не соромтесь робити issues та PR's ?.

https://github.com/yakimka/picodi