Можно подробнее, я не понял. Если имеете в виду сделать Setting датаклассом, мне кажется это не очень подходящее применение
почему? настройки это буквально просто набор каких-то параметров - данных
Ну там есть нормально так логики. Но даже если использовать датаклассы как это решит мою проблему.
откуда в настройках логика?
А методы по получению включенных опций в настройках, проверки все ли выбраны и тд это не считается логикой?
ладно, это норм. Но это во всех случаях разное.
А как использование датаклассов решило бы проблему хранения setting_name и тд
я так и не понял что за setting name, зачем он нужен и что за проблема
Мне нужно различать настройки разные поэтому для однозначной идентификации им были присвоены имена (setting_name) Пока Setting был абстрактным я просто создавал новый класс: class CarsSetting(Setting): setting_name: Final[str] = "cars" default_sections = { "cars": Section( [ ... ] ), } И в нем указывал setting_name, поэтому я мог не хранить setting_name в redis. Но когда я отказался от такого подхода и выбрал создание экземпляров класса Setting: cars_settings = Setting(setting_name=..., ...) То мне теперь нужно хранить еще и setting_name в redis, и я хочу этого избежать
не понял что значит "различать". У тебя разные настройки лежат в разных полях, всё. Этого достаточно чтобы их различить @dataclass class CarSettings: engine: int @dataclass class SuperSettings: car: CarSettings ну или что там за логика, я не понял. Что за секции, зачем нужен name - что происходит? ТЫ явно не о настройках говоришь, а о чем-то более сложном
а можешь с самого начала что там в редис у тебя? куча сеттингов по разным ключам лежат жсонами? сеттинги каждый про что-то своё? или разные сеттинги для одного и того же?
Когда есть имена к определенной настройке легче обращаться в других частях программы, чем по индексу.
какому ещё индексу?
вот опять же можно сначала? как получилось что у тебя они по индексам лежат?
Обсуждают сегодня