Так то можно переопределить run в bottle, и в mro он не возьмется из первого класса в наследовании, но наверное это говнокод)

а вот кстати хорошо что ты натолкнул меня на мысль - а какая действительно вызовется функция?...

Ну так это

Почитай про method resolution order

Почитай про method resolution order

не думаю что питон сильно отличается от других языков. А у всех всегда чтототипа "кто последний тот и папа"

А вот с змейкой как раз таки наоборот

Если я не ошибаюсь

А вот с змейкой как раз таки наоборот

зависит, но в в общем лучае левый предок будет вызван первым.

спасибо

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

задача в чем? запустить bottle из другого потока?

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

я это понимаю, и super уже убрал

super() то как раз наиболее правильный способ обращаться к базовым классам

ты нахрена-то влез в класс Bottle, отнаследовался от него, поимел проблем с множественным наследованием на ровном месте…

@lowit_agr будет жить. Поприветствуем!

задача в чем? запустить bottle из другого потока?

смотри... Не просто из другого потока... Ща на пальцах.... Есть два друга - прометей и графана. Оба два умеют дёргать за вебхуки. У меня есть уже проект - обсервер. "плагинная" реализация. Сейчас умеет читать/матчить логи и срать переделлаными по шаблону результатами в телегу Хочу ещо два плагина. Под графану и прометея соответственно боттл при запуске держит поток. Следовательно нужно в отдельном потоке. threadhelper у меня уже есть, нужно только переопределить метод run() так как вебхук штука простая, то можно и это превратить в базовый для двух плагинов класс, переопределяя метод обработки хука. Как то так.

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

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

смотри... Не просто из другого потока... Ща на пальцах.... Есть два друга - прометей и графана. Оба два умеют дёргать за вебхуки. У меня есть уже проект - обсервер. "плагинная" реализация. Сейчас умеет читать/матчить логи и срать переделлаными по шаблону результатами в телегу Хочу ещо два плагина. Под графану и прометея соответственно боттл при запуске держит поток. Следовательно нужно в отдельном потоке. threadhelper у меня уже есть, нужно только переопределить метод run() так как вебхук штука простая, то можно и это превратить в базовый для двух плагинов класс, переопределяя метод обработки хука. Как то так.

правильно ли я понял, что под прометей и графану ты хочешь по плагину с тредом на каждый и инстансом bottle на борту?

правильно ли я понял, что под прометей и графану ты хочешь по плагину с тредом на каждый и инстансом bottle на борту?

да. Крах одного не должен мешать другому.

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

да о чем и речь. его пример выше брать, есть ненулевой шанс поиметь проблем из-за того что он super() не использует

да о чем и речь. его пример выше брать, есть ненулевой шанс поиметь проблем из-за того что он super() не использует

какие проблемы? К чему быть готовым?

какие проблемы? К чему быть готовым?

простой пример https://pastebin.com/dgpALrkj

что именно, вызов сразу инита вебхука? Можно просто поменять местами ИнпутПлагин и Вебхук в наследовании, тогда вызывать через super, либо оставить как есть и тогда с помощью super(InputPlugin, self) проскочить одну ступень в мро. Но вообще вызов двух инитов - это какая-то херня, зачем это? Нужно просто вызвать super().__init__(...), тот вызовет инит плагина, который в свою очередь - инит вебхука

что именно, вызов сразу инита вебхука? Можно просто поменять местами ИнпутПлагин и Вебхук в наследовании, тогда вызывать через super, либо оставить как есть и тогда с помощью super(InputPlugin, self) проскочить одну ступень в мро. Но вообще вызов двух инитов - это какая-то херня, зачем это? Нужно просто вызвать super().__init__(...), тот вызовет инит плагина, который в свою очередь - инит вебхука

следует ли это читать как "питон не умеет в множественное наследование"? На самом деле печально конечно что тут так плохо с этим. Не ожидал, ей богу, сижу расстроенный ((

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

следует ли это читать как "питон не умеет в множественное наследование"? На самом деле печально конечно что тут так плохо с этим. Не ожидал, ей богу, сижу расстроенный ((

следует читать "я не представляю себе, как работать со множественным наследованием"

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

а если я везде вызов super уберу, оно всё равно будет дважды вызывать конструкторы как в https://pastebin.com/dgpALrkj ?

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

а если я везде вызов super уберу, оно всё равно будет дважды вызывать конструкторы как в https://pastebin.com/dgpALrkj ?

class Derived(Base1, Base2): def __init__(self): super().__init__() print('Derived.__init__')

class Derived(Base1, Base2): def __init__(self): super().__init__() print('Derived.__init__')

base1 и base2 у меня ожидают различные параметры в конструктор

похоже придётся в dict всё оборачивать...

и переименовывать метод у threadhelper

или плюнуть да к чертям обратно в плюсы...

base1 и base2 у меня ожидают различные параметры в конструктор

какая им разница? Всё, с чем нужно что-то сделать выше по иерархии - можно кинуть через *args, **kwargs

да. Крах одного не должен мешать другому.

странная логика если честно, что мешает обрабатывать исключения per request, более того это уже зашито в веб-фреймворк. максимум что должно упасть - отдельный обработчик запроса.

какая им разница? Всё, с чем нужно что-то сделать выше по иерархии - можно кинуть через *args, **kwargs

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

или плюнуть да к чертям обратно в плюсы...

это очень здравая мысль

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

это не костыль, это нормальная практика передачи неопределённого количества аргументов по цепочке вызовов

странная логика если честно, что мешает обрабатывать исключения per request, более того это уже зашито в веб-фреймворк. максимум что должно упасть - отдельный обработчик запроса.

я бы хотел чтобы свалился поток целиком, освободив память и всё такое прочее.

это не костыль, это нормальная практика передачи неопределённого количества аргументов по цепочке вызовов

"неопределенное количество параметров" - я про это. Это - костыль

данные должны быть строго определены и по возможности строго типизированны

"неопределенное количество параметров" - я про это. Это - костыль

каким местом это костыль? Это способ разделения ответственности

данные должны быть строго определены и по возможности строго типизированны

кому должны?

я бы хотел чтобы свалился поток целиком, освободив память и всё такое прочее.

я очень осторожно поинтересуюсь, ты случайно ничего не путаешь

каким местом это костыль? Это способ разделения ответственности

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

я очень осторожно поинтересуюсь, ты случайно ничего не путаешь

могу путать. 2 ночи всётаки, а я человек

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

более того тебе придется в свой и так полный костылей код навернуть логику мониторинга вывалившихся потоков, что лучше бы отдать на откуп systemd и в случае критичной ошибки вывалить сервис целиком.

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

я читаю это так:"чувак пришёл из плюсов, пытается писать что-то на питоне, но продолжает писать на плюсах и удивляется, что это не работает"

с процессом видимо спутал. Сплю уже почти (

более того тебе придется в свой и так полный костылей код навернуть логику мониторинга вывалившихся потоков, что лучше бы отдать на откуп systemd и в случае критичной ошибки вывалить сервис целиком.

так исключения же есть

крч... если я буду вызывать init руками, то нарвусь на множественные запуски родительских конструкторов, так? Пойду переписывать код под один dict в конструкторе, раз уж питон иначе не тянет :(

с другой стороны - полезный опыт, спасибо

крч... если я буду вызывать init руками, то нарвусь на множественные запуски родительских конструкторов, так? Пойду переписывать код под один dict в конструкторе, раз уж питон иначе не тянет :(

у тебя уже есть этот дикт, называется **kwargs

лучше уж приведи конкретный пример, что не получается

у тебя уже есть этот дикт, называется **kwargs

предпочитаю явно указывать переменные, без магии

хотя бы искуственный пример с аргументами инитов и иерархией

^

предпочитаю явно указывать переменные, без магии

так это херовый дизайн, если метод, который не имеет отношения к этим аргументам, требует их явно

зачем вообще передавать в инит аргументы типа self.whatever, если можно их получить из self уже на месте?

так это херовый дизайн, если метод, который не имеет отношения к этим аргументам, требует их явно

этого делать бы не пришлось если бы питон нормально умел множественное наследование

я читаю это так:"чувак пришёл из плюсов, пытается писать что-то на питоне, но продолжает писать на плюсах и удивляется, что это не работает"

https://youtu.be/R-FfI4i0-uY?t=752

этого делать бы не пришлось если бы питон нормально умел множественное наследование

питон отлично умеет множественное наследование, в частности не провоцирует на херовый дизайн

зачем вообще передавать в инит аргументы типа self.whatever, если можно их получить из self уже на месте?

потому что этот класс может унаследоваться другим, у которого нет self_options

ERROR: S client not available

питон отлично умеет множественное наследование, в частности не провоцирует на херовый дизайн

Не умеет питон в полной мере множественное наследование. Ибо конструкторы тогда должны быть идентичными. Что, в принципе делает сие наследование часто бесполезным

он же троллит ?

https://youtu.be/R-FfI4i0-uY?t=752

странный чел. Сильно самовлюблен.

ну такое, смотрю его тупо порофлить, рассказывает интересно

потому что этот класс может унаследоваться другим, у которого нет self_options

да блин, ну почитай уже хоть основы по питону, чтобы разговор был хоть немного конструктивен. Когда у тебя класс Derived(Parent), и цепочка вызовов через super, то в Parent будет тот же self, что в Derived

да блин, ну почитай уже хоть основы по питону, чтобы разговор был хоть немного конструктивен. Когда у тебя класс Derived(Parent), и цепочка вызовов через super, то в Parent будет тот же self, что в Derived

я понимаю это

А ты понял что я написал?

или просто буквы посмотрел

могу повторить

Не могу понять, один и тот же код при работе с selenium.phantomjs... На серваке CENTOS7 сайт ничего не возвращяет, просто None, на Windows 7 всё ок

WebhookHelper может унаследовать другой объект

могу повторить

попробуй, повтори

у которого нет self._options

https://pastebin.com/VE1SN7Ft

могу повторить

и про 20 лет опыта не забудь

у которого нет self._options

ты вызываешь super() из объекта, в котором есть self._options, значит этот же self._options будет там, куда тебя отправит super

ты вызываешь super() из объекта, в котором есть self._options, значит этот же self._options будет там, куда тебя отправит super

ты не понял

еще раз

WebhookHelper может унаследовать другой объект

у которого нет self._options

и у его родителей нет self._options

и у его дочерей нет self._options

пожтому я параметризирую этот объект в его конструкторе

при вызове конструктора

так не проще на месте поискать, есть они или нет?

при создании объекта

так не проще на месте поискать, есть они или нет?

нет, не проще

потому что сначала искать лдно

потом другое

следом третье

не дофига ли лишних движений вметсо того чтобы передать в конструктор сразу правльное?

похоже что там в один класс понапихано куча всего