огород при обходе дерева наследований?
Уточню что в рекурсивной функции, которая формирует дерево наследников, я формирую экземпляр класса, назову например Х.
После чего мне требуется достать экземпляр родительского (по отношению к Х) класса, ради атрибута.
А тут, собственно говоря, мозгов и не хватает.
То ли просто сначала формировать дико вложенные списки классов, затем проводить по ним инициализацию, и исходить из этого, или реализовать Синглтон, но это говномагия, либо ещё какую-то хрень выдумывать...
Ты там метаклассы хреначишь что делаешь наследников динамически? Или в subclasses добавляешь? Поясни получше
Это один из обозначенных мною вариантов - собрать сначала многократно вложенный список из наследников. Который мне не то чтоб нравится.Всё равно там придётся рекурсивно обходить, а тут и проблема - как в рекурсивке получить доступ к родителю
Хуй знает, видимо наилучшим среди худшего - словарь вида {cls: экземпляр cls}...
Залезь в new метод магический И сделай что бы каждый наследник автоматически при инициализации инстанса добавлялся в какую либо структуру у базового класса
По сути сделал это же самое, но через словарик в управляющем этой вакханалией классе
Может минимальный пример дать?
Синглтон == глобальная переменная. Какую задачу ты решаешь вообще? Зачем ты обходишь дерево наследований?
Повторяю (частично) механизм ORMок, где классами задана некоторая структура. Пример в предыдущем сообщении. Собираю наследников, инициализирую, работаю с их атрибутами.
Что за «механизм ORMок»? Это что такое?
ORM знаешь что такое? Алхимия например?
Знаю, непонятно, что ты подразумеваешь под «механизмом ORMок»
Обозначение таблиц классами.
Ты ORM делаешь свою?
Нет, но переношу описанную механику на новую задачу
Дёрнуло меня заняться какой-то хуйней, вот и задаю сюда странные вопросы
Немного им пользовался. Опиши проблему давай
Мне странно что ты инициализируешь инстансы обходя наследников базового класса
Вероятно ты использовал вторую версию. Речь за тройку, но думаю будет понятно. Я решил спиздить механизм описания таблиц БД в ORM, и перенести его для хендлеров аиограмма.
Нет, там инициация сначала родителя, затем всех наследников 1-уровня и т.д.
А зачем для этого что-то городить? Ты слышал про super() и mro?
Да, но тогда ещё больше хрень получается. Он ищет в другую сторону - от дальнего наследника к родителю. А у меня обратная ситуация
Что? MRO не так работает
Одна хуйня, ты уже ступил на дорожку сомнительной магии
Ну, в этот раз мета вроде не нужна. Единственное, на чём я проебался - если сразу хуярить например class BasicCommands(...): router = Router() @router.message() async def start(self, m: Message): ... То улетает в аиограм непроинициализированный метод. То есть self идёт нахуй, что нехорошо. И тут наступает пиздец, ибо надо либо какую-то прокладку, чтобы уже потом подать в аиограм метод проинициализированного класса, или забить хер на self, а этого не хочется.
А ты не можешь залезть в router? Ну отнаследуй его по самые нехочу, и как то где то там вызывай метод сам не передевая то что передавал оригинальный роутер
Вот это и есть по-видимому единственный вариант. Ну, кроме как забить на self конечно.
Правда потом будет такой говнокод, шо пиздц, из-за особенности нейминга параметров роутеров в аиограмме
Ну там твоя простыня, потом позиционные, не позиционные, аргсы, кваргсы, / и просто * Такой комбинацией почти все можно оверрайднуть
Там такая хуйня блять, что нельзя сделать условный router.register('message', args, kwargs) Там идёт router.message.register(...) То есть либо надо наследовать вообще всё нахуй, и менять только атрибут, в таком случае корневое обращение получается getattr(router, "message").register(...) Словом, весело.
Передавай аёграмму не класс а инстанс, определи call, херани аргсы кваргсы и работой из call с селф))) без проблем
Не, хуйня какая-то. Хендлер на класс точно не пойдёт
Разве что сделать декоратор сразу на весь класс, сделать роутер-прокладку, и уже там что-то изобретать...
print(“Hello World”)
Ахахахха
Обсуждают сегодня