Комментарии 15
По мне, это правила того, как не надо писать код. Неужели, напихивание кучи разных функций в одну предобработку (по оптимизацию памяти пока не будем говорить) читается лучше, чем один шаг - одно действие? Суть пандаса всегда была в простоте и понятности кода. Для меня, например, совсем не удобно читать спарковский стайл кода (когда в одну ячейку запихивают кучу всего). Соответственно, написание подобного кода в команде, это как ванлайнеры - выглядят может и красиво, но читать коллегам (разных уровней) не удобно. "Милорды" может и пишут так код (хотя очень сомневаюсь), но чтобы джуны/мидлы могли легко читать/писать ванлайнеры - это из области фантастики.
Анти-паттерн №2: применение циклов for при работе с объектами pandas DataFrame
Интересно посмотреть на то, каким образом должен выглядеть "правильный и оптимальный код", если нужно проходиться по каждой строке ДФ и брать определенные данные из нужных колонок каждой строки.
в итоге есть функция - split_prod_countries.
Для чего писать функцию на чтение файла и переименование колонок, чтобы потом всего один раз воспользоваться этим? Ну это же глупо. Функции пишутся, когда один функционал нужно применить несколько раз в рамках кода, судя по этому "итого" несколько функций пишутся только для "смотри как я могу".
https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.DataFrame.filter.html
https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.DataFrame.applymap.html
это подходит вместо for?
У меня была проблемка, и эти два метода не выглядят подходящими. Суть задачи была в следующем: нужно создать функцию, которая получая датафрейм, должна построить отсортированную таблицу корреляций с заданным порогом, чтоб можно было сразу же увидеть, какие из признаков сильнее всего коррелируют. Т.е. на выходе датафрейм с двумя столбцами: первый - названия пары фич, второй - корреляция между ними.
Начало кода вышло таким:
cormap = df.corr()
cormap = cormap * (np.tril(np.ones(cormap.shape[0]), -1))
# убираем диагональ т.к. там единицы, и верхний треугольник,
# т.к. матрица зеркальна относительно диагонали.
mask = (cormap > min_corr) | (cormap < -min_corr)
# находим все значения корреляции выше порога, разумеется учитывая
# как сильную положительную, так и сильную отрицательную корреляции
highcor = cormap[mask].dropna(how='all', axis=0).dropna(how='all', axis=1)
# выбразываем все строки и столбцы в которых сильная корреляция не обнаружена.
# Это больше нужно было для того чтобы визуально оценить уменьшенную версию
# матрицы 10х10 вместо, скажем, 30х30. Этот шаг можно пропустить
idx = highcor.stack().reset_index().drop(0,1).apply(tuple, axis=1).tolist()
# получаем список пар индексов(row, col), в которой мы обнаружили корреляциюИ на этом месте сталкиваемся с обломом, что этот список не получится использовать напрямую для получения списка соответствующих значений. Приходится выстраивать новый датафрейм через for добавляя строку за строкой. Какого-то метода сделать все "по красивому" без for я не нашел к сожалению. Хотя можно конечно утешить себя тем, что конкретно в этом случае вопрос производительности не важен, т.к. у нас таблица врядли будет иметь более пары десятков строк, и всего два столбца, так что можно наверно и так оставить.
Зачем всё это если сам создатель панд говорит о том, что пандас неэффективен и нужно уходить от него?
На что?
I strongly feel that Arrow is a key technology for the next generation of data science tools. I laid out my vision for this recently in my JupyterCon keynote.
Подробней в блоге Wes McKinney
И кстати arrow не менее прекрасен и в R тоже
И помимо отличного arrow есть ещё и polars
Я правильно понял, что arrow не является заменой pandas? Arrow, если я правильно понял, - это более низкоуровневая библиотека, скорее замена protobuf, может быть numpy. Заменой pandas является polars, который работает поверх arrow. А есть другие хорошие альтернативы pandas? Есть другие DataFrame engines поверх arrow?
Есть убийственно эффективный data.table на R (регулярно пользуюсь) и вариант его портирования на питоне datatable.
Насколько эффективен питоновский-сказать не могу, не использовал.
Немного кликбейтно. Я бы назвал просто "4 полезных приема для работы с Pandas". А тут аж прям с ходу АНТИ-ПАТТЕРНЫ!!! Я аж залез читать - вдруг как-то не так панду юзаю :)
При работе с данными, которые впервые видишь очень стремно торопиться - это самый главный анти-паттерн на мой взгляд. Лучше шаг-ячейка-шаг-ячейка. А так да, у панды есть Function application - иногда весьма полезная штука.
Самое интересное, иногда понимаешь, что в некоторых простых случаях можно вообще на одном НамПае что-то нехитрое сделать. Но все равно import pandas as pd...
А кто-то может знает как можно применить определенные функции агрегации после groupby к каждой группе целиком, а не к конкретным колонкам? Просто насколько я понимаю после groupby создается кортеж из записей на каждую группу. И иногда приходится для каждой группы циклом что то костылить
Возможно подойдёт вызов `.apply()` на сгруппированный df, а внутри него для каждой группы применить `group_df.assign()`
Если после groupby применять apply, то он будет применяться к группам. Например, df.groupby('nm').apply(lambda x: x.fillna(x.mean())) заполнит пропуски разным средним для каждой группы по колонке nm.
4 анти-паттерна pandas и способы борьбы с ними