Как-то сегодня никто нормально не пошутил. Только Тинёк про кэшбек на камушки с пляжа и Razer выдал классический кринж-девайс.

Рассказывайте, какие еще первоапрельские приколы увидели. Может я просто пропустил.

А в 2009 году вышел PEP 401, в котором объявили о замене оператора != на <> и отказе от CPython 😂

https://peps.python.org/pep-0401/

Ну что, еще помните для чего нужны __slots__? Про них все слышали, но никто не использует 😅

Идея слотов проста - каждый раз, создавая экземпляр класса питон хранит все объекты в словаре __dict__. У словарей есть свои накладные расходы. А если мы указываем __slots__, то теперь для хранения используются кортежи. Они экономнее и быстрее.

Разница в памяти около 30% на ровном месте. Есть и прирост в скорости создания экземпляров. А так же в скорости доступа к атрибутам.

Есть особенности:
- Слоты не наследуются. У каждого дочернего класса нужно прописывать заново.
- Нельзя динамически добавлять атрибуты в класс
- При указании слотов пропадает поддержка слабых ссылок. Лечится добавлением __weakref__ в слоты вручную.

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

Простой пример тут

#python

Все становится только хуже 😂

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

⚙️ Round Robin (RR)
Раздаёт запросы по очереди — 1→2→3→1...

✅ Простота и скорость
✅ Работает «из коробки» почти везде
❌ Не учитывает загрузку сервера
❌ Если железо на серверах разное — слабый сервер захлебнётся, пока более мощные будут простаивать
❌ Не учитывает сложность запросов. На один сервер может упасть десяток долгих POST-запросов, пока другие получат простой GET и будут простаивать

Где есть: везде (nginx, haproxy и т.д.)

⚙️ Weighted Round Robin (WRR)
То же самое, что и RR, только с возможностью указать “вес” сервера. На мощный сервер — 3 запроса, на слабый — один запрос.

✅ Учитывает разную мощность железа
❌ Вес статичен
❌ Легко забыть обновить веса в конфиге при изменениях
❌ Также не учитывает сложность запросов

Где есть: везде (nginx, haproxy и т.д.)

⚙️ Least Connections (LC)
Направляет трафик туда, где меньше активных соединений

✅ Учитывает текущую "загруженность"
✅ Идеально для долгих сессий (WebSocket, RDP)
❌ Не различает лёгкие и тяжёлые соединения
❌ Игнорирует мощность железа

Где есть: haproxy, traefik

⚙️ Least Response Time (LRT)
Измеряет время ответа сервера и шлёт туда, где быстрее

✅ Умный выбор по реальной скорости
✅ Быстро реагирует на "тормоза"
❌ Чувствителен к сетевым "скачкам"
❌ Нужно заморочиться с health check’ами

Где есть: haproxy (встроенно), nginx (с Lua/расширениями)

⚙️ IP Hash
Клиенты с одного IP всегда попадают на один сервер

✅ Простая привязка сессии без кук
✅ Подходит для stateful-приложений
❌ Перегрузка, если много клиентов за одним NAT
❌ Удаление сервера = обрыв сессий

Где есть: nginx, haproxy

⚙️ Resource-Based (Адаптивная)
Агенты на серверах следят за CPU, RAM, I/O и передают данные балансировщику.

✅ Максимальная точность по загрузке
❌ Требует настройки агентов, метрик и логики

Где есть: traefik, haproxy (Lua), кастомный nginx

Отдельно стоит упомянуть health check’и. Если TCP-порт открыт — это ещё не значит, что всё работает. Надежнее использовать HTTP/HTTPS-запрос на специальный endpoint (например, /health) с проверкой внутренних зависимостей (доступность базы, очередей, кеша и т.д.). Это создаёт дополнительную нагрузку, поэтому настройке нужно уделить внимание — частота, таймауты, и какие компоненты действительно критичны.

P.S Естественно про каждый вид балансировки стоит почитать отдельно, все тонкости не уместятся ни в одну шпаргалку ✍️

Недолюбливаю JavaScript. Но иногда приходится на нём писать. Уникальный язык, в котором смогли сделать плохо практически всё. Одни только типы и их сравнения чего стоят ([] == ![] — ну вы поняли).

Сегодня вот познакомился поближе с его асинхронностью. Проблема была в старом коде: где-то в глубине вызывается API, чтобы обновить объект. Я вызываю обычную функцию UpdateObject — ничего подозрительного. Ни async, ни await. Значит она точно завершится до следующей строки, всё как мы любим. Хаха, наивный питонист. Здесь другие правила.

Оказывается, внутри она делает асинхронный вызов, но снаружи этого не видно. Просто где-то уходит запрос к API — без await, без явных признаков асинхронности. А ты такой вызываешь UpdateObject() и думаешь: ну раз функция обычная, значит всё выполнится до конца. Ан нет.

В данном случае fetch вернёт Promise (аналог нашей футуры) и выполнится когда то потом.

function updateObject() {
  fetch("https://jsonplaceholder.typicode.com/todos/1");
  console.log("🟢 updateObject завершён");
}

updateObject();
console.log("⏹️ Основной поток завершился");

По итогу получим следующее:

🟢 updateObject завершён
⏹️ Основной поток завершился
✅ fakeApiCall завершён

В Питончике в этом плане всё прозрачнее. Хочешь асинхронщину — пиши async def. Делай await. Ты не можешь в случайном месте вызвать асинхронную функцию. Это однозначно благо. Всё видно, всё понятно, есть правила. Да, это строже, да, есть ограничения. Но и забористый говнокод таким образом написать гораздо сложнее.

Могу поделиться с вами большой радостью!) Выпустил первое видео на YouTube. Сделать всё в первый раз - целое приключение, но всё получилось.
Поддержите подпиской.
https://www.youtube.com/watch?v=s9weaYfkkv4

Самые "любимые" грабли. Сделал фичу, гоняешь локально - всё супер. Позже приходит тестировщик — “там твоё говно пятисотит, вернул в бэклог”. Ну класс, приехали 🫡

Проблема всегда одна - в БД у разработчиков обычно весьма ограниченное сочетание данных. Часто вообще заводится один объект под конкретную фичу. А на тестовых/продовых стендах ситуация совсем другая, там всякого добра навалом. И каждый раз там находится что-нибудь, до чего бы я даже не догадался Чем меньше знаешь проект - тем чаще попадаешься на такие сюрпризы.

В итоге закрыл для себя эту проблему полным дампом БД с тестового стенда, который содержит все возможные извращения, которые только можно придумать. Ну и соответственно локальная проверка кода стала в разы объективнее.

P.S А как вы решаете эту проблему?

Недавно читал статью про оптимизацию PostgreSQL. Там была фраза "Пишите запросы вручную, ORM переоценён". Причём статейка подаётся как от "разработчика к разработчикам", но как такой "совет" может дать человек в здравом уме - не понимаю. Тут мол вам и n+1, и кривые джойны, и магия "под капотом". Ну чтож, разберёмся чуть подробнее.

Проблема с N+1 - явно надуманная и решается на любой ORM без танцев с бубном. Джойнится всё в большинстве случаев самым оптимальным образом. Если вдруг нет - обычно всё решается небольшими изменениями в коде и достаточно предсказуемо. Вот про магию под капотом так вообще хохма. Давайте вспомним зачем нужна ORM? Для работы с данными, как с объектами. Это абстракция над SQL. Чтобы думать про то, что сделать, а не "как". Это буквально придумали для того, чтобы снизить сложность.

В тот момент, когда человек по любому чиху бежит писать запросы на чистом SQL мы буквально гвоздями себя приколачиваем к текущей схеме данных. Редачить даже десяток сырых запросов после каждого изменения схемы - вот это настоящий ад. Даже если всё покрыто тестами (а оно не всегда покрыто). В добавок сырые запросы дико проиграют по читаемости. Попробуй еще сообрази, что там происходит и что мы получим. А что получаем в замен? Возможно ощущение, что "мы молодцы, умеем в sql", ну и собственно всё.

Так что перед тем, как писать сырой SQL нужно явно убедиться, что задача реально недостижима при помощи ORM. Иначе - это неоправданное переусложнение.

В Python 3.14 появились t-строки. Да, мало нам было f-строк. Теперь еще и строки-шаблоны. Для того, чтобы понять зачем они вообще появились стоит вспомнить основной недостаток наших любимых f-строк. По сути всё исходит из невозможности перехватить и дополнительно обработать переданное значение. Всё потому что сразу собирается итоговая строка. А вот t-строка возвращает нам сырой шаблон и мы сами решаем, как его рендерить.

Вот небольшой пример того, как литерал t преобразует строку в объект Template, тем самым давая нам доступ к объекту шаблона:

from string.templatelib import Template

name = "World"
template = t"Hello {name}"
isinstance(template, Template) # 👉 True
print(template.values)  # 👉 ("World",)

Рендеринг t-строк выглядит страшновато:

from string.templatelib import Template, Interpolation

def lower_upper(template: Template) -> str:
    """Render static parts lowercased and interpolations uppercased."""
    parts: list[str] = []
    for item in template:
        if isinstance(item, Interpolation):
            parts.append(str(item.value).upper())
        else:
            parts.append(item.lower())
    return "".join(parts)

name = "world"
assert lower_upper(t"HELLO {name}") == "hello WORLD"

В голове ноль идей, где бы я мог это применить. Но и особого вреда они тоже не принесут.
Полный текст PEP 750: https://peps.python.org/pep-0750/

#python #python3_14

Интересное: ChatGPT периодически фантазирует вокруг PEP. Про некоторые PEP'ы он очень уверенно рассказывает полную чушь.
К примеру:

- Что за pep 758? В одном предложении
- PEP 758 вводит системный мониторинг зависимостей Python через pip, позволяя пользователям получать уведомления о уязвимостях и обновлениях через pip audit.

ТЗ то есть, но проблема не в этом

Еще кое что про Python 3.14. В нём же появился PEP 758. Теперь можно перечислять группу эксепшнов без скобок. Проще показать:

Раньше только так:

try:
    ...
except (ExceptionA, ExceptionB, ExceptionC):
    ...

Теперь можно и так:

try:
    ...
except ExceptionA, ExceptionB, ExceptionC:
    ...

Полный текст PEP 758: https://peps.python.org/pep-0758/

#python #python3_14

А вы знали, что в Python есть группы исключений и возможность зайти в каждый except блок, а не только в первый?

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

try:
    raise ExceptionGroup("eg",
        [ValueError(1), TypeError(2), OSError(3), OSError(4)])
except* TypeError as e:
    print(f'caught {type(e)} with nested {e.exceptions}')
except* OSError as e:
    print(f'caught {type(e)} with nested {e.exceptions}')

# caught <class 'ExceptionGroup'> with nested (TypeError(2),)
# caught <class 'ExceptionGroup'> with nested (OSError(3), OSError(4))
#   + Exception Group Traceback (most recent call last):
#   |   File "<stdin>", line 2, in <module>
#   | ExceptionGroup: eg
#   +-+---------------- 1 ----------------
#     | ValueError: 1
#     +------------------------------------

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

#python #python3_11

Последнее время прям дико прут настоящие бумажные книги. Это я старею? Или это у всех так?

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

На фото так сказать "чтение на лето" из трех книг. DDD, кабанчик и (внезапно) постгрес. Но что-то мне подсказывает, что за лето я не успею...

DDD вот почти победил, надеюсь на выходных получится дочитать и потом поделиться с вами самым интересным 👍

P.S Делитесь, что читаете? 👇