➡️ Python Set Methods — шпаргалка

Собрали все основные методы множеств в Python в одном компактном гайде.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека питониста

#буст

👇 Как правильно типизировать декораторы в Python

Декораторы — штука мощная, но для типизации долгое время были настоящим кошмаром. Кажется логичным сказать: «декоратор принимает функцию и возвращает такую же функцию». На практике mypy отвечает ошибками, потому что wrapper теряет исходную сигнатуру.

Вот как обычно пытаются сделать (и почему это ломается):

from functools import wraps
from typing import Any, Callable, TypeVar

F = TypeVar("F", bound=Callable[..., Any])

def info(func: F) -> F:
    @wraps(func)
    def wrapper(*args: Any, **kwargs: Any) -> Any:
        print(func.__name__)
        return func(*args, **kwargs)

    return wrapper  # mypy: incompatible return type

Типизатор видит, что wrapper — это уже другая функция с Callable[..., Any], а не тот же F.

Правильное современное решение — ParamSpec, который сохраняет параметры исходной функции:

from functools import wraps
from typing import Callable, ParamSpec, TypeVar

P = ParamSpec("P")
R = TypeVar("R")

def info(func: Callable[P, R]) -> Callable[P, R]:
    @wraps(func)
    def wrapper(*args: P.args, **kwargs: P.kwargs) -> R:
        print(func.__name__)
        print(func.__doc__)
        return func(*args, **kwargs)

    return wrapper

Теперь сигнатура полностью «протаскивается» через декоратор и mypy счастлив.

А в Python 3.12+ это стало ещё красивее благодаря PEP 695:

from functools import wraps
from typing import Callable

def info[**P, R](func: Callable[P, R]) -> Callable[P, R]:
    @wraps(func)
    def wrapper(*args: P.args, **kwargs: P.kwargs) -> R:
        print(func.__name__)
        print(func.__doc__)
        return func(*args, **kwargs)

    return wrapper

Без лишних объявлений, всё читается почти как generics в статически типизированных языках.

➡️ Подробная статья

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека питониста

#буст

🪄 Самая крутая фича Python 3.14 — удалённый дебаг без подготовки

Отладка Python-приложений в Docker и Kubernetes — боль.

Новая фича Python 3.14 — sys.remote_exec() превращает всё это в почти магию.

sys.remote_exec() позволяет выполнить Python-скрипт внутри уже запущенного процесса:
🔵 без перезапуска
🔵 с полным доступом к памяти, модулям и состоянию
🔵 прямо на лету

Идеально, чтобы вколоть debugpy в живое приложение.

И собственно, debugwand — zero-prep remote debugger для Python в контейнерах:
🔵 Находит нужный pod или контейнер
🔵 Выбирает правильный Python-процесс (учитывает `uvicorn --reload`)
🔵 Инжектит debugpy через sys.remote_exec()
🔵 Сам настраивает port-forwarding
🔵 Ты просто подключаешься из VS Code / nvim / любого DAP-клиента

Подключаешься к localhost:5679 — и у тебя полноценный дебаг: breakpoints, step-by-step, inspect variables.

📱 debugwand

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека питониста

#буст

seapie: отладчик, где брейкпоинт — это просто `>>>`

seapie — это отладчик, который думает как человек, а не как учебник по gdb.

Без зависимостей, ставится одной командой и превращает отладку в обычный Python-REPL:

pip install seapie

Идея радикально простая:
брейкпоинт — это не клик мышкой и не спец-синтаксис, а обычный интерактивный >>>.

✔️ В seapie много подсказок, понятные ошибки и встроенная помощь, до которой можно дотянуться в любой момент.

✔️ Во-вторых, отладка через намерение, а не шаги.

seapie позволяет сказать: «остановись, когда функция вернёт None и в стеке будет myhelper» — обычным Python-выражением:

>>> !walk (_event_ == "return") and (_return_ is None) and ("myhelper" in _callstack_)

✔️ В-третьих, REPL-first по-настоящему.
Посмотреть переменную — это print(x) или просто x.
Поменять — x = None.
Команды отладчика живут рядом и не ломают мышление.

А состояние программы — это обычный словарь:

>>> _magic_
{
  '_line_': 8,
  '_source_': '    return round(total_with_tax, 2)',
  '_path_': '/home/hirsimak/seapie/test/demo.py',
  '_return_': 35.64,
  '_exception_': None,
  '_event_': 'return',
  '_callstack_': ['<module>', 'checkout']
}

👉 Github

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека питониста

#буст

🐸 Библиотека питониста

#развлекалово

➕ Как уменьшить память и ускорить доступ к атрибутам в Python-классах

По умолчанию каждый объект в Python хранит атрибуты в __dict__.

Гибко — да. Эффективно — не всегда:

class Point:
    def __init__(self, x, y, z):
        self.x = x
        self.y = y
        self.z = z

p = Point(1, 2, 3)
print(p.__dict__)
# {'x': 1, 'y': 2, 'z': 3}

У каждого экземпляра — свой словарь. Добавили p.w = 4 — словарь вырос:

p.w = 4
print(p.__dict__)
# {'x': 1, 'y': 2, 'z': 3, 'w': 4}

🚫 Но если структура объекта фиксированная, мы платим лишнюю цену за эту гибкость.

Решение: __slots__:

class Point:
    __slots__ = ('x', 'y', 'z')

    def __init__(self, x, y, z):
        self.x = x
        self.y = y
        self.z = z

Поведение меняется:

p = Point(1, 2, 3)
p.x = 10      # ок
p.w = 4       # ❌ AttributeError

И главное:

p.__dict__
# ❌ AttributeError: object has no attribute '__dict__'

Что меняется:
🔴 больше нельзя добавлять произвольные атрибуты
🔴 нет __dict__
🔴 меньше памяти на каждый объект
🔴 чуть быстрее доступ к атрибутам

Python хранит значения в компактной структуре, а не в словаре.

Используйте __slots__, если:
🔴 у вас тысячи / миллионы объектов
🔴 структура объектов фиксированная
🔴 важны память и производительность

Не стоит, если:
🔴 объект — «мешок с атрибутами»
🔴 нужна динамика и расширяемость

🔗 Статья с примерами

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека питониста

#буст

🖥 Топ-вакансий для питонистов за неделю

Если вы обещали себе найти новую работу после праздников — вот тот самый «после» 🙂

Python Developer — от 3 000 $, удалёнка

Python developer (SRE Agent), удалёнка

LLM Engineer (Python, RAG) — от 200 000 ₽, удалёнка

🔛 Еще больше топовых вакансий — в нашем канале Python jobs

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека питониста

#буст

🐼 Релиз: Pandas 3.0

21 января 2026 вышел pandas 3.0.

Вот что реально стоит знать 👇

✔️ Строки теперь — не object

Раньше строки в pandas = object.
Туда можно было засунуть что угодно. Медленно. Неявно. Больно.

Теперь по умолчанию:

pd.Series(["a", "b"]).dtype
# str

Что это даёт:
— dtype только для строк
— единая семантика пропусков (`NaN`)
— лучше память и производительность

Это давно назревшее исправление архитектурной ошибки.

✔️ Copy-on-Write: конец адскому chained assignment

Главное правило pandas 3.0: любой срез — ведёт себя как копия:

df2 = df[df.a > 0]
df2["b"] = 10   # больше НИКОГДА не меняет df

Что изменилось:
— SettingWithCopyWarning — удалён
— «а тут view или copy?» — больше нет
— модифицируешь объект → модифицируй его напрямую

Под капотом pandas всё ещё оптимизирует память. Но API теперь честный.

✔️ pd.col() — выражения без лямбд

Было:

df.assign(c=lambda df: df.a + df.b)

Стало:

df.assign(c=pd.col("a") + pd.col("b"))

✔️ Arrow C Interface — zero-copy будущее

Pandas теперь:
— умеет принимать Arrow-таблицы
— умеет отдавать их без копирования

df.__arrow_c_stream__()

✔️ Новый порядок депрекейтов

Теперь всё прозрачно:
— Pandas4Warning → сломается в 4.0
— Pandas5Warning → сломается в 5.0

⚠️ Совет: обновитесь сначала до 2.3, уберите warning’и — и только потом идите в 3.0.

🔗 Ссылка на релиз

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека дата-сайентиста

#буст

🤖 LFM2.5-1.2B-Thinking — бронирует билеты сам

Небольшой Python CLI, который ищет и бронирует авиабилеты через tool calling и reasoning.

✍️ Просто пишешь: «найди самый дешёвый рейс из Барселоны в Белград на 2026-01-31» — и агент сам разбивает задачу на шаги и решает её.

Проект — демо возможностей LFM2.5-1.2B-Thinking: маленькой, но умной модели, заточенной под логические задачи, цепочки действий и вызов инструментов.

👌 И да — она может работать на edge-устройствах.

📱 Проект

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека питониста

#буст

🧪 PyTest: как параметризовать тесты с исключениями

Иногда нужно прогнать разные входные данные и проверить, что в одних случаях код работает, а в других — выбрасывает нужное исключение.

✖️ Делать отдельный тест под каждый кейс — не всегда разумно.

Для этого удобно комбинировать pytest.mark.parametrize с contextlib.nullcontext:

from contextlib import nullcontext as does_not_raise
import pytest
from pytest import raises


@pytest.mark.parametrize(
    ["x", "y", "expectation"],
    [
        (3, 2, does_not_raise()),
        (0, 1, does_not_raise()),
        (1, 0, raises(ZeroDivisionError)),
        (1, "0", raises(TypeError)),
    ],
)
def test_division(x, y, expectation):
    with expectation:
        x / y

Подход простой:
🔵 если исключения не ожидается — используется nullcontext
🔵 если ожидается — pytest.raises(...)
🔵 все сценарии живут в одном параметризованном тесте

Метод описан в документации PyTest и обсуждался на StackOverflow, но на практике о нём знают не все.

Хорошо подходит, когда:
🔵 проверки на исключения однотипные
🔵 не хочется раздувать тестовый набор
🔵 нужно аккуратно покрыть все ветки кода

nullcontext — не самая очевидная часть стандартной библиотеки, но алиас does_not_raise делает намерение теста понятным с первого взгляда.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека питониста

#буст

🐸 Библиотека питониста

#развлекалово

➡️ Бенчмарк Python API фреймворков: FastAPI vs Django vs Litestar

Свежий бенчмарк сравнивает основные Python API-фреймворки на реальных PostgreSQL-нагрузках, а не на синтетическом JSON. Сложные запросы, вложенные связи, корректный eager loading для каждого стека — всё как в проде.

➡️ Главный вывод довольно отрезвляющий:
разница в производительности схлопывается, как только появляется база данных.
Если на простом JSON разброс достигает ~20×, то на пагинации это уже ~1.7×, а на сложных запросах — всего ~1.3×.

➡️ При правильно оптимизированных запросах FastAPI, Django (DRF, Ninja, Bolt) и Litestar показывают почти одинаковые результаты. Бутылочное горлышко — Database I/O, а не сам фреймворк.

➡️ Тесты запускались в изолированных Docker-контейнерах с жёсткими лимитами по CPU и памяти, на разных продакшен-серверах (Uvicorn, Granian, Gunicorn). Это честное сравнение именно архитектурных различий, а не случайных настроек.

➡️ Bottom line простой:
для database-heavy API имеет смысл тратить время на оптимизацию запросов и моделей данных, а не на бесконечный выбор «самого быстрого» фреймворка — при нормальном коде они все почти равны.

🔗 Код, цифры и воспроизводимый сетап: https://clc.to/D47EDw

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека питониста

#буст

📱 Python новости за последние 7 дней

Flask в 2025: итоги года и состояние экосистемы
Жив ли Flask в эпоху FastAPI? Короткий ответ — да. Длинный — экосистема стала спокойнее, взрослее и менее хайповой.

Claude Code в 2026: гайд для тех, кто ещё пишет код руками
Немного провокационный, но полезный материал о том, как ИИ меняет процесс разработки. После прочтения хочется либо уволиться, либо автоматизировать всё подряд.

CPython — сборка мусора изнутри
Для тех, кто любит знать, что именно происходит под капотом.

Собираем LLM-агента на Python
Практический гайд по созданию AI-агента без лишней теории.

Pandas 3.0 — релиз
21 января 2026 вышел pandas 3.0 — большой апдейт с важными архитектурными изменениями. Обновляться стоит, но сначала лучше прочитать, что именно поменяли, чтобы потом не удивляться внезапным багам.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека питониста

#свежак