➕ Как уменьшить память и ускорить доступ к атрибутам в 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 — большой апдейт с важными архитектурными изменениями. Обновляться стоит, но сначала лучше прочитать, что именно поменяли, чтобы потом не удивляться внезапным багам.

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

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

#свежак

🐸 Библиотека задач по Data Science

Туториалы по FastAPI

Серия туториалов о том, как с нуля собрать полноценное веб-приложение на FastAPI.
Будет и JSON API для программного доступа, и HTML-страницы для работы через браузер.

По ходу разбирается:
— база данных с SQLAlchemy
— валидация данных через Pydantic
— полный CRUD
— структура проекта, близкую к продакшену

🔗 Ссылка на уроки

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

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

#буст

🐼 Что нового в pandas 3.0 — наш детальный взгляд

Мы уже делились, что вышел pandas 3.0. Сегодня чуть более детально о том, что реально изменилось:

📍Наконец-то убили SettingWithCopyWarning

Тот самый «адский ворнинг» при работе со срезами DataFrame — всё.

В pandas 3 полностью внедрён Copy-on-Write:
— фильтрации больше не копируют данные сразу
— копия создаётся только при мутации
— .copy() после каждого шага больше не нужен
— предупреждение исчезло

👍 Это одно из самых важных UX-улучшений за годы.

📍Новый синтаксис выражений — pandas.col()

Method chaining в pandas всегда выглядел громоздко из-за lambda:

.assign(max_people=lambda df: df.max_people + df.max_children)

Теперь можно писать как в Polars / PySpark:

.assign(max_people=pandas.col("max_people") + pandas.col("max_children"))

📍UDF больше не приговор к «очень медленно»

.apply() раньше = боль и падение производительности.

В pandas 3 появился интерфейс execution engines.
Теперь UDF можно JIT-компилировать:

df.apply(func, axis=1, engine=bodo.jit())

Код остаётся понятным Python и производительность может быть выше векторизованного варианта.

📍Строки и Arrow

Полного «Arrow внутри pandas» не случилось.

Вместо этого:
— новый dtype: str
— под капотом может быть Arrow или legacy, в зависимости от окружения
— больше совместимости, меньше боли при апгрейде
— но всё ещё 3 разных способа хранить строки

🔗 Подробно с примерами в статье

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

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

#буст

Python для собеседований. Вопрос: В чём разница между *args и **kwargs?

Когда мы пишем функции в Python, чаще всего знаем, сколько аргументов они будут принимать. Но иногда это неизвестно заранее. Именно для таких случаев существуют *args и **kwargs.

Чтобы их понять, сначала разберёмся с двумя базовыми типами аргументов.

(a) Позиционные аргументы (Positional Arguments)

Это аргументы, которые передаются в функцию в определённом порядке:

def greet(name, age):
    print(f"Hello {name}, you are {age} years old")

greet('Shiva Shankar', 30)
greet('Narayanan', 32)

первый аргумент → name
второй аргумент → age

Если перепутать порядок:

greet(31, 'Lakshmi')

Python всё равно выполнит вызов, но:
name = 31
age = 'Lakshmi', что логически неверно.

(b) Именованные аргументы (Keyword Arguments)

Здесь мы явно указываем, какому параметру что соответствует. Порядок уже не важен:

greet(name='Ganesh', age=25)
greet(age=21, name='Karthikeya')

Так код читается лучше и снижает риск ошибок.

🔛 Различия

*args позволяет функции принимать любое количество позиционных аргументов. Внутри функции они собираются в кортеж:

def calculate_total(*prices):
    total = 0
    for i, price in enumerate(prices, 1):
        print(f"Item {i}: {price}")
        total += price
    print(f"Total: {round(total, 2)}")

calculate_total(10.5, 20, 5.75)

prices → это кортеж: (10.5, 20, 5.75)

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

**kwargs позволяет принимать любое количество именованных аргументов. Внутри функции они собираются в словарь:

def show_order(**kwargs):
    total = 0
    for i, (item, price) in enumerate(kwargs.items(), 1):
        print(f"{i}. {item}: {price}")
        total += price
    print(f"Total: {round(total, 2)}")

show_order(apple=2.5, milk=1.8, bread=2.2)

kwargs:

{'apple': 2.5, 'milk': 1.8, 'bread': 2.2}

Ключи — названия, значения — данные.

🔛 Использование вместе: *args + **kwargs

def shopping_cart(*items, **prices):
    print("Items:")
    for i, item in enumerate(items, 1):
        print(f"{i}. {item}")

    print("\nPrices:")
    total = 0
    for i, (item, price) in enumerate(prices.items(), 1):
        print(f"{i}. {item}: {price}")
        total += price

    print(f"\nTotal bill: {round(total, 2)}")

shopping_cart(
    "Shoes", "T-shirt",
    Shoes=50, Tshirt=20
)

items → позиционные данные (что купили)
prices → именованные данные (цены)

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

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

#буст