Pandas 3.0 сломал мой пайплайн — Copy-on-Write это боль или благо?

[jownby]

Обновился до Pandas 3.0 на рабочем проекте (ETL-пайплайн, ~15k строк кода). Наткнулся на массовые предупреждения ChainedAssignmentError, которые в 3.0 стали реальными ошибками — Copy-on-Write теперь включён по умолчанию и обратной совместимости нет. Особенно больно в местах вроде df[df['col'] > 0]['other_col'] = value — это раньше работало через раз и было известной проблемой, теперь просто падает. Кто уже прошёл эту миграцию на боевом коде — есть ли автоматические инструменты для поиска проблемных мест, или только ручной аудит?

[linux_lord]

Есть ещё нюанс с многоуровневой индексацией и GroupBy — там CoW поведение иногда неочевидное. Рекомендую после миграции прогнать тесты с включённым gc.collect() между операциями и смотреть на утечки памяти. У нас вылезла одна нетривиальная проблема именно с groupby().apply() где внутренняя функция мутировала переданный датафрейм — раньше это работало, теперь мутация не проходит наружу. Пришлось переписать на явный return.

[sergeyserov]

Полезный лайфхак для постепенной миграции на больших репозиториях: в начале каждого скрипта ставьте import warnings; warnings.filterwarnings('error', category=pd.errors.ChainedAssignmentError) — это превращает варнинги в ошибки ещё на 2.2, и CI начинает ловить проблемные места до апгрейда. Мы так мигрировали за 3 спринта без единого инцидента на проде.

[navspy]

@jownby, Прошёл примерно такую же миграцию на датасайенс-проекте. Инструмента «найди всё автоматически» нет, но помогает такой подход: запускаешь код с pd.options.mode.copy_on_write = 'warn' на Pandas 2.2 перед апгрейдом — он выдаёт предупреждения именно там, где в 3.0 будут ошибки. Собираешь все варнинги в лог, потом последовательно правишь. У меня было около 340 предупреждений, реальных ошибок оказалось 87 — остальное было просто переизбыточным копированием, которое теперь исключено.

[juniorredteam]

@jownby, Конкретный паттерн замены: вместо df[mask]['col'] = val пишите df.loc[mask, 'col'] = val. Это работало правильно и раньше, просто раньше первый вариант иногда тоже работал случайно. Если нужно именно модифицировать копию — явно делайте df2 = df[mask].copy(), потом df2['col'] = val. Читаемость кода от этого только выигрывает — сразу видно, где создаётся новый объект.

[seniorsamurai]

@jownby, CoW — это на самом деле благо для продакшена, просто миграционная боль неизбежна. После перехода у нас pipeline стал потреблять на 18% меньше RAM на тех же данных — pandas перестал делать невидимые копии датафреймов в каждой операции. На датасетах по 10-20 GB это ощутимо. Но да, неделю чинили старый код.