Наткнулся на статью “Как Python чуть не стал JavaScript’ом”. В одной из бета-версий Python 3.12 был добавлен класс AttrDict. Этот класс, по сути, является обычным словарём, но позволяет получать доступ к элементам не только через квадратные скобки, но и через точку.

То есть, если создать такой словарь:

d = AttrDict(x=1, bar=2)
print(d)
# {'x': 1, 'bar': 2}

То можно получить доступ к элементам как через квадратные скобки, так и через точку:

print(d.x)
# 1
print(d.bar)
# 2

Причём pull request сделал один человек, даже без ревью. Но потом довольно быстро его откатили назад. Один из аргументов за такую функцию был в том, что это реализовано в Pandas, где можно обращаться к колонке как через квадратные скобки, так и как к атрибуту через точку. Однако, как сказал автор видео: “Pandas не является хорошим примером для подражания”. И самое интересное, что в комментариях многие с ним согласны.

https://www.youtube.com/watch?v=nDd2WVb_Enw&t=171s&ab_channel=anthonywritescode

Людям сразу после курсов сложно найти работу. Есть разные версии, почему. Кто-то говорит, что курсы плохие. Кто-то видит причину в том, что виноваты работодатели, которые не хотят брать джунов.

Мне кажется, что проблема не в этом, а в том, что три месяца, полгода и даже год — это мало для получения серьезной профессии. Посмотрим хотя бы на среднее специальное образование. Не буду рассуждать на тему полезности, пригодности в жизни, устарелости программы. Оно занимает три года. Год из этого — это школьная программа 10-11 классов. Остается два года обучения профессии, причем два года обучения full-time. Полдня учишься в аудитории, а потом еще дома. Если сравнивать с высшим образованием, то даже если выкинуть нерелевантные курсы, все равно получится больше двух лет.

То есть наши "деды", которые придумывали систему образования, закладывали минимум два года на освоение профессии. По сравнению с этим даже год — это мало. Тем более подразумевается, что курсы можно совмещать с работой, то есть это не full-time.

Бывает такое, что получаешь сообщение.

Произошла авария, которая затронула работу системы Х. И теперь Х не работает.

И каждый раз я думаю, а правда ли это авария, или у вас просто что-то упало? Не слишком ли громкое слово авария. Когда я вижу слово авария, хочется представить метеорит, который упал на датацентр. Или администраторов, которые голыми руками выпонят жесткие диски из пожара.

Но что-то мне подсказывает, что чаще всего это и близко не так. Скорее всего кто-то где-то накосячил, что-то нажал и что-то сломалось. Причем сломалась какая-нибудь хрень, которая не тянет на такое громкое слово. Лично я всегда использую слово сломалось или упало в таких случаях.

Не используйте метод drop в ваших data пайплайнах. Из-за drop неясно, какие колонки остаются в получившемся датасете.

Читая код, не понимаешь, какие поля обязательные. Особенно сложно, если в коде большая вложенность.

def fun1(df: pd.DataFrame) -> pd.DataFrame:
# some code
return df.drop("price", axis=1)

def fun2(df: pd.DataFrame) -> pd.DataFrame:
# some code
df = fun1(df)
return df.drop("total_sum", axis=1)

df = pd.read_csv"path)
def fun3(df: pd.DataFrame) -> pd.DataFrame:
df = fun2(df)
# some code
return df.drop("cluster_id", axis=1)

Вот сиди и думай, какой список полей на выходе из fun3.
Сначала нужно понять, что находится в датафрейме, который читается. Потом разобраться, какие колонки дропаются на выходе каждой из функций. Еще неясно, какие колонки добавляются. Придется искать их по всему коду.

Если же каждый раз явно указывать список полей, то все становится понятно:

def fun3(df: pd.DataFrame) -> pd.DataFrame:
df = fun2(df)
# some code
return df[["product_id", "store_id", "sales", "volume"]]

На заре своей карьеры я работал в компании Pfizer. Сейчас она известна благодаря одноименной вакцине. Но восемь лет назад, когда говорили о Pfizer, многие путали её с брендом шоколадок Fazer.

При онбординге нужно было проходить множество различных тренингов и обучений. Один из них рассказывал о том, что необходимо сообщать компании обо всех случаях незадокументированных эффектов от применения лекарств, производимых Pfizer. Например, если кто-то столкнулся с головной болью, не описанной в побочных эффектах, нужно обязательно сообщить компании. Причем неважно, столкнулся ли с этим я сам, кто-то из моих знакомых или я вычитал об этом в соцсетях.

Эти эффекты не обязательно должны быть отрицательными. Если после таблетки от головной боли улучшилось зрение, об этом тоже нужно сообщить.

Нам не рассказывали, с какой целью это делается. Но я предполагаю, что необычные, даже положительные эффекты могут быть признаком скрытых процессов, которые пока проявляются безобидно, но в будущем могут проявиться более серьезно.

С похожими ситуациями я сталкивался при работе с данными. Несколько раз возникала следующая ситуация: я занимаюсь пайплайном обработки данных и замечаю какой-то мелкий косяк — немного дублей или непонятные NaN. Я игнорирую эти мелкие косяки, а через несколько дней нахожу серьезную ошибку в пайплайне обработки данных. Оказывается, что всё неправильно, криво приджойнилось или что-то в таком духе. А те мелкие косяки, которые я видел за несколько дней до этого, могли бы указать на проблему раньше, если бы я обратил на них внимание.

Поэтому я стараюсь обращать внимание даже на мелкие ошибки, потому что они могут быть признаками более существенных проблем.

Заказчик, который хочет 100% точность или 0% ошибок, вызывает недоумение. Невозможно построить модель, которая никогда не будет ошибаться и будет 100% точной. Но реально построить модель, у которой точность будет лучше текущего решения. И нет ничего страшного в том, что модель будет ошибаться. В среднем, на дистанции, она будет приносить value. Это понятно. С этим никто не спорит.

Но почему-то всех напрягает следующая ситуация. Мы провели 100500 А/B тестов. Из них тысячи оказались успешными. Но мы понимаем, что среди этих тысяч есть эксперименты, которые мы ошибочно посчитали успешными. Я считаю, что в этом нет ничего страшного. Из этих тысяч фичей, которые мы протестировали, какие-то не влияют, какие-то влияют отрицательно. Но к этому стоит относиться спокойно. Так же стоит относиться спокойно к тому, что у модели не 100% точность.