В какой-то момент моего путешествия по Python ООП я наткнулся на классы данных . Я смутно припоминаю, что это происходило при генерации, казалось бы, повторяющегося шаблонного кода для класса, который делал лишь немного больше, чем содержал довольно длинную запись данных. Надеясь, что есть лучший способ сделать это, я открыл для себя классы данных, которые были введены в Python 3.7 (через PEP 557 ).

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

В этом посте я хотел поделиться некоторыми открытиями, касающимися более интересных реализаций классов, а также тем, как такие «интересные» классы данных могут быть легко использованы модулем анализа данных Python pandas .

«Интересный» класс данных

Следующий список представляет собой то, что я считаю «интересным» в смысле того, что может произойти в реальной жизни при создании класса данных :

• Свойства, которые генерируют значения атрибутов - возможно, без базового атрибута класса (т.е. чистое свойство). Их можно рассматривать как уровни обработки данных с семантикой атрибутов (по сравнению с методами).
• Атрибуты только для чтения
• Поля только для инициализатора
• Свойства, которые генерируют значения атрибутов на основе полей только для инициализатора
• Атрибуты инициализируются дополнительным списком или типом dict
• Атрибуты, которые мы не хотим экспортировать в DataFrame pandas

• attr5 - это чистое свойство, которое доступно только для чтения и получает свое значение из поля только для инициализатора attr0 . Не существует базовой переменной класса, отражающей значение attr5 . Обратите внимание на фиктивный установщик , который требовался модулю dataclasses, чтобы заставить его поверить, что он настраивается. Нам также пришлось определить это с помощью атрибута управления полем init = False, чтобы исключить его из генерации метода __init __ ().
• attr4 принимает список для инициализации, которая требует, чтобы default_factory возвращала пустой объект списка, когда список не был предоставлен
• _attrHidden является копией инициализатора только attr0 и предназначен для спрятана . Мы выполняем эту копию в __post_init __ () метод
• rand_factory - это метод класса, единственная цель которого - генерировать рандомизированные объекты этого класса. Подробнее об этом ниже, когда мы обсуждаем панд

Теперь, когда мы определили наш класс данных с различными «интересными» функциями, давайте посмотрим, насколько легко получить DataFrame pandas, построенный из списка случайных экземпляров DataClass_Modern .

Просматривая приведенный выше код, сразу видно, что это очень просто. Сначала мы сгенерировали список из 100 случайных объектов, используя наш метод rand_factory () . Затем мы просто передаем этот список непосредственно конструктору DataFrame по умолчанию .

Слишком легко!

А как насчет следующего?

• Экспортируется ли attr5 в DataFrame, как мы ожидаем?
• Подавляется ли экспорт attr0 и _attrHidden в DataFrame, как мы могли ожидать?

Это должно быть сюрпризом? В некотором роде. Как бы это работало, если бы мы не использовали классы данных ?

Создание фрейма данных pandas с «классическим» классом

Приведенный ниже фрагмент кода представляет собой эквивалентное определение класса, ориентированного на данные, со всеми «интересными» функциями, которые нам нужны, с использованием стандартной структуры классов Python, определяемой пользователем. Теперь, если это можно было сделать несколькими способами, но здесь мы сохраним простоту и сделаем это как можно ближе к базовому определяемому пользователем классу.

На первый взгляд ясно, что для этого потребовалось немного больше работы (и на самом деле она неполная, как мы вскоре увидим). Обратите внимание, как нам пришлось обращаться с инициализатором списка и как мы должны были предоставить наш собственный метод __str __ () . Однако нам не нужно было предоставлять фиктивный сеттер для attr5 .

В приведенном выше фрагменте кода видно, что мы используем специальный метод конструктора from_dict . Это происходит потому , что мы используем __dict__ встроенного метода для DataClass_Classic объектов , чтобы получить атрибуты. Это выглядит достаточно просто, но как на самом деле выглядит DataFrame при использовании такого же краткого подхода?

Две проблемы:

1. _attrHidden экспортируется. Мы этого не хотели . Неудивительно, потому что __dict__ действительно будет включать «скрытые» атрибуты (т. Е. Те, которые начинаются с подчеркивания). В случае , если вам интересно, а Dunder (двойной подчеркивание) не помогает. Фактически, версия без искажений (с полным префиксом имени класса) экспортируется в DataFrame.
2. Где attr5 ?? Кажется, нигде не найти. Это происходит потому , что __dict__ является ДИКТ из атрибутов класса при вызове на объекте. Атрибут attr5 на самом деле является иллюзией. Это просто метод, украшенный синтаксическим сахаром в качестве псевдонима для метода getter () . Обратите внимание , что добавление фиктивного сеттера метод не помогает. Создание атрибутов таким способом является очень распространенным шаблоном в Python, поскольку он может обеспечить уровень обработки данных с семантикой атрибута (вместо вызова метода).

Сказав это, чтобы иметь очень расширенный контроль над экспортом определяемого пользователем класса в DataFrame , классический подход все еще более эффективен, если вы хотите делать такие вещи, как контроль, какие атрибуты не включаются во время построения во время выполнения или объект обрабатывается как столбец pandas (но это выходит за рамки данной статьи).

Наблюдения

Я обычно помечаю последний раздел любого сообщения в блоге как «Выводы», но в данном случае это будет вводить в заблуждение. Вместо этого мы просто сделали несколько наблюдений:

• Использование классов данных сокращает повторяющийся и шаблонный код. Для простых классов, ориентированных на данные, реализация на основе классов данных всегда будет намного более лаконичной (и, следовательно, более простой для чтения и сопровождения). Классы данных имеют гораздо больше функций, таких как возможность сравнения объектов, которые не обсуждались в этой статье, что снова делает их очень подходящими для приложений, ориентированных на данные.
• Можно реализовать более продвинутое поведение атрибутов с помощью классов данных, таких как сгенерированные атрибуты только для чтения, поля только для инициализации и инициализаторы на основе фабрики (которые также могут использовать лямбда-функции )
• dataclasses предоставляют очень простой интерфейс для создания pandas DataFrame s. Удивительно, но конструкция следовала семантическому замыслу скрытых атрибутов и атрибутов, основанных исключительно на свойствах.
• Более продвинутое построение DataFrame может потребовать использования стандартных классов Python. Проверка этого обычно подтверждается необходимостью искажать реализацию класса данных для достижения чего-то, что в противном случае было бы просто с обычным классом.