Комментарии 9
Помню, как то еще в университете была тема про то, что иногда (а может и часто) замена одного высокоуровневого кода на другой почти ничего не меняет внутри исполняемой программы... вы просто одно прячете внутрь другого. Это тонкие вещи, но они есть.
Например: в коде вызывается какая то функция, написанная вами, а в другой версии аналогичная функция стала конструкцией самого языка (или его библиотеки) и вот вопрос: а повысится ли эффективность кода от того, что теперь вы исключите вызов своей и станете вызывать уже готовую или по сути при исполнении это ни на что не повлияет?
ну и так далее... вопрос весьма философский зачастую
Все что упрощает код - хорошо.
замена даже трехстрочной функции на вызов одного метода из стандартной библиотеки языка / сторонней библиотеки - это упрощение кода, а значит это хорошо. (Это конечно, при условии что сторонняя библиотека более-менее известна.)
Это упрощает чтение и содержание кода, а так же снижает когнитивную нагрузку на читателя кода.
Замена одного высокоуровнего участка на другой - это чаще всего обертки, которые заменяют собой часто встречающиеся фрагменты / операции, что тоже отлично
В целом все верно написано, но можно немного добавить, если хочется короче и быстрее:
1) Если заменить точки и пробелы в заголовках полей df - можно в 5+ раз сократить число набираемых символов при обращении к каждому полю df['col'] -> df.col
Также не придется нигде использовать f-строки
2) пустоты лучше всего визуализировать чем-то готовым, типа:
import missingno as msno
msno.matrix(df)
3) вместо .apply(lambda x: 0 if pd.isna(x) else 1) итп - в десятки раз быстрее будет np.where(col.isna(), 1, 0) Но в контексте анализа - названия спринтов могут пригодиться. Есть категоризация данных: df.col.astype('category') Получаем возможность работать с числовыми кодами и строками категорий, уменьшаем данные в RAM в 5-20 раз, ускоряем отбор в 4-8 раз, появляется возможность упорядочить спринты в опр. (вашем) порядке.
4) df.filter() умеет работать и со строками, и со столбцами, а значит все списковые включения вида df[[x for x in df.columns if '_count' in x]] можно заменить на df.filter(like='_count')
Фраза "У аналитика есть минимальный опыт погружения в программирование" как-то резанула. И на неё обидится большинство аналитиков ибо в большинстве случаев всё ровно наоборот))). Предлагаю заменить её на "У Саши есть минимальный опыт погружения в программирование"
Я один из тех аналитиков,которые не знают Python, от слова "совсем". Зашёл в аналитику со стороны VBA,Power Query,Power BI, MDX, DAX, SQL.
Вышеперечисленного стека хватает на все задачи с лихвой,но я хочу немного уйти в сторону прогнозирования и расширить свои знания и начал немного учить R в прошлом году, но не хватило самодисциплины,хотя кое-чему научился)))),сейчас пытаюсь подступиться к Python,пока читаю книгу Byte of Python.
Твоего перечисленного стэка хватит с лихвой лишь на ETL и BI. То что ты забросил R и хорошо и плохо одновременно: в R есть всё необходимое для анализа данных , и каждый из этих тулзов гораздо производительнее и не менее функционален чем в python (а зачастую - более). Но если смотреть на рынок труда то питон у работодателей востребованней в анализе данных : заслуга чисто за счёт всей оставшейся инфраструктуры (бэкэнд, web, etc) на нём же.
R - очень классный язык, но вот у меня так получилось,что на моей текущей позиции задач для него немного,верней не то,чтобы немного,просто стек который я знаю реализует эти задачи и так. И тут конечно использовал R только в тех случаях,когда моего стека не хватало,а это прогнозирование парой десятков моделей и выбор наилучшей из них, кластеризация,интеграция в Power BI.
Ту причину,что вы озвучили,относится и ко мне. Я думаю, что однажды вернусь к R, Python пока идет легче.)))
Ошибки начинающего аналитика при обработке данных на Python: учить пандас на табличках 3*33 вместо производительного и современного polars/pyarrow и потом на реальных бизнес задачах плакать натягивая свой пандас_код на даск
Ошибки начинающего аналитика при обработке данных на Python: 4 всадника апокалипсиса