Я цілком усвідомлюю, що pylintта інші інструменти статичного аналізу не є всезнаючими, і іноді їхні поради повинні бути не дотримані. (Це стосується різних класів повідомлень, а не лише conventions.)
Якщо у мене є заняття на кшталт
class related_methods():
def a_method(self):
self.stack.function(self.my_var)
class more_methods():
def b_method(self):
self.otherfunc()
class implement_methods(related_methods, more_methods):
def __init__(self):
self.stack = some()
self.my_var = other()
def otherfunc(self):
self.a_method()
Очевидно, це надумано. Ось кращий приклад, якщо вам подобається .
Я вважаю, що цей стиль називають використанням "міксинів".
Як і інші інструменти, pylintставки цей код в -21.67 / 10першу чергу тому , що він думає , more_methodsі related_methodsне мають selfабо атрибути otherfunc, stack, annd my_varбо без виконання коду, він , очевидно , не може бачити related_methodsі more_methodsзмішують в до implement_methods.
Компілятори та інструменти статичного аналізу не завжди можуть вирішити проблему зупинки , але я вважаю, що це, безумовно, випадок, коли дивлячись на те, що успадковано, implement_methodsбуло б показано, що це абсолютно вірно, і це було б дуже легко зробити.
Чому інструменти статичного аналізу відкидають цю дійсну (я думаю) схему OOP?
Або:
Вони навіть не намагаються перевірити спадщину чи
міксини відбиваються від ідіоматичного, читаного Python
№1, очевидно, неправильно, тому що якщо я попрошу pylintсказати мені про мій клас, який успадковує, unittest.TestCaseякий використовує self.assertEqual, (щось визначене лише в unittest.TestCase), він не скаржиться.
Чи міксини непітонічні чи не відсторонені?
