Модели на dataclasses

[MarshalX]

Идея с pydantic хороша, но кажется избыточной в рамках данной библиотеки. Никто никогда не будет проверять соответствие типов полей с присланной ЯМ информацией.

Намного проще и легче использовать средства встроенные в язык. С Python 3.7 у нас есть стандартная библиотека dataclasses.

Инициируя переезд с текущих моделей я преследую следующие цели:

• избавиться от ужасных конструкторов в которых 0 байт полезной информации. Просто присваивание большого перечня полей который еще надо указывать в аргументах
• избавиться от документирования конструктора. Это такой же мертвый груз как и сам конструктор. Никто никогда не будет использовать конструкторы вручную. Библиотека сама создается все необходимые объекты. Единственное место где используются конструкторы - это тесты моделей. Для конечного программиста-потребителя это абсолютно не надо.

Переезд на dataclasses можно осуществлять в несколько итераций. Первая - это избавление он конструкторов и документации к ним с сохранением всех старых функциональных возможностей. Старое сравнение моделей, их хеширование, доступ к полям, сообщения о новых неизвестных полях. Вторая - новый подход к сериализации и десериализации на десктрипторах.

На текущий момент я уже переписал 1 модель на dataclass, она красиво вписалась в текущий проект. У меня имеются следующие заметки:

• необходимо отключать автогенерирование __eq__ потому что оно происходит по всем полям (дока). Соответственно каждый декоратор класса будет выглядеть так: @dataclass(eq=False). Конечно можно вынести в utils создав свой декоратор над этим и контролировать аргументы с одного места в коде.
• датаклассы так же генерируют конструктор, что нам и надо, но не умеют в unexpected keyword аргументы, которые используются сейчас чтобы библиотека не падала при получении нового поля от обновленного API. Кроме этого **kwargs используются для логирования новых полей в консоль. Для решения это проблемы я написал в базовом классе фильтрацию исходного словаря, который пришел от сервера, по существующим полям модели. В библиотеке есть функция dataclasses.fields возвращающая перечень полей, у которых есть имена. Так я смог создать два словаря: известные поля, неизвестные поля. Одни идут в конструктор для создания модели, вторые выводятся в консоль как новые. Повторю, что это находится в базовом классе и теперь нет необходимости в каждом конструкторе вызывать super().handle_unknown_kwargs(self, **kwargs).
• из прошлого пункта появляется проблема, что теперь нет необходимости в конструкторе делать аргумент id_ вместо id, потому что это зарезервированное имя. Мы в целом больше не будет работать и заботиться о конструкторах. Из-за того, что сейчас принудительно всем зарезервированным именам дописывается в конец _, существует разница имени поля и имени аргумента. В dataclasses нет возможности задавать псевдонимы для аргументов конструктора. Поэтому при переезде придется отказаться от добавления _ в конец, что собственно не есть плохо. Конечные программисты будут взаимодействовать с полями классов как и раньше. Например, Track.id.
• следующая проблема в том, что конструктор автогенерируемый. Теперь нет возможности в нем задать атрибуты для сравнения моделей, которые будут участвовать в генерации хеша и в операции сравнения. Но для обратной совместимости сравнения (и не только) этот перечень атрибутов задавать где-то надо. Я перенес объявление атрибутов для сравнения в переопределенный __hash__. Можно занести это под if, если мы не хотим их переопределять каждый раз, а просто смотреть не были ли они заданы уже при первом сравнении.
• из-за прошлого пункта, где атрибуты теперь устанавливаются только при вызове hash(), у нас перестает работать сравнение, которое работало исключительно на том самом перечне атрибутов. Я изменил логику сравнения с сравнения перечня атрибутов на сравнение хешей, которые генерируются по этим самым атрибутам + классу. Таким образом при вызове __eq__ у нас вызывается hash() на левый и правый операнд, а они в свою очередь, перед просчетом хеша, устанавливают перечень атрибутов. Вероятно, теперь при сравнении должна упасть производительность из-за частого вызова просчета хеша, в котором присутствует заморозка вложенных списков.

Учтя все заметки выше получаем рабочую библиотеку с поддержкой старой логики и прохождение всех текущих тестов моделей даже при комбинации 1 dataclass'a со всеми старыми моделями

P.S. реализация всего этого приведет к прекращения поддержки Python 3.6

[MarshalX]

Для инициализации перечня атрибутов (_id_attrs) можно использовать

__post_init__()

В таком случае не надо переделывать eq базового класса

[MarshalX]

Идея реализована в рамках этой задачи: #469