Sono pienamente consapevole del fatto che pylinte altri strumenti di analisi statica non sono onniscienti, e talvolta i loro consigli devono essere disobbediti. (Questo vale per varie classi di messaggi, non solo per conventions.)

Se ho lezioni simili

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()

Ovviamente, è inventato. Ecco un esempio migliore, se vuoi .

Credo che questo stile sia chiamato "mixin".

Come altri strumenti, pylinti tassi di questo codice -21.67 / 10, in primo luogo perché pensa more_methodse related_methodsnon hanno selfo attributi otherfunc, stack, gustato my_var, perché senza correre il codice, a quanto pare non può vedere related_methodse more_methodssi mescolano-in a implement_methods.

I compilatori e gli strumenti di analisi statica non possono sempre risolvere il problema dell'arresto , ma penso che questo sia certamente un caso in cui guardare ciò che è ereditato implement_methodsdimostrerebbe che questo è perfettamente valido e che sarebbe una cosa molto semplice da fare.

Perché gli strumenti di analisi statica rifiutano questo modello OOP valido (credo)?

O:

1. Non provano nemmeno a controllare l'eredità o

2. i mixin sono scoraggiati in Python idiomatico e leggibile

# 1 è ovviamente errato perché se chiedo pylintdi parlarmi di una mia classe che eredita unittest.TestCasequell'uso self.assertEqual(qualcosa definito solo in unittest.TestCase), non si lamenta.

I mixin non sono ritonici o scoraggiati?

I mixin non sono solo un caso d'uso considerato dallo strumento. Ciò non significa che sia necessariamente un caso di cattivo utilizzo, solo un caso insolito per Python.

Se i mixin siano usati in modo appropriato in un caso particolare è un'altra questione. L'anti-pattern di mixin che vedo più frequentemente sta usando i mixin quando c'è sempre e solo una combinazione. Questo è solo un modo per nascondere una classe divina. Se non riesci a pensare a una ragione in questo momento per scambiare o tralasciare uno dei mixin, non dovrebbe essere un mixin.

Credo che i Mixin possano essere assolutamente Pythonic. Tuttavia, il modo idiomatico di mettere a tacere la tua linter - e migliorare la leggibilità dei tuoi Mixin - è sia di (1) definire metodi astratti che definiscono esplicitamente i metodi che i figli di un Mixin sono tenuti ad attuare, sia di (2) pre-definire None-valutato campi per i membri dei dati Mixin che i bambini devono inizializzare.

Applicando questo modello al tuo esempio:

from abc import ABC, abstractmethod


class related_methods():
    my_var = None
    stack = None

    def a_method(self):
        self.stack.function(self.my_var)


class more_methods(ABC):
    @abstractmethod
    def otherfunc(self):
        pass

    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()

Penso che i mixin possano essere buoni, ma penso anche che il pilone sia giusto in questo caso. Disclaimer: segue materiale basato sull'opinione.

Una buona classe, compresi i mixin, ha una chiara responsabilità. Idealmente, un mixin dovrebbe portare tutto lo stato a cui accederà e la logica per gestirlo. Ad esempio, un buon mixin potrebbe aggiungere un last_updatedcampo a una classe di modello ORM, fornire la logica per impostarlo e metodi per cercare il record più vecchio / più recente.

Fare riferimento a membri di istanza non dichiarati (variabili e metodi) sembra un po 'strano.

L'approccio giusto dipende molto dal compito da svolgere.

Potrebbe essere un mixin con il bit di stato rilevante contenuto in esso.

Potrebbe trattarsi di una gerarchia di classi diversa in cui i metodi attualmente distribuiti tramite un mixin si trovano in una classe di base, mentre le differenze di implementazione di livello inferiore appartengono alle sottoclassi. Questo sembra più adatto al tuo caso con le operazioni dello stack.

Può essere un decoratore di classe che aggiunge un metodo o due; questo di solito ha senso quando devi passare alcuni argomenti al decoratore per influenzare la generazione del metodo.

Indica il tuo problema, spiega le tue maggiori preoccupazioni di progettazione, quindi potremmo discutere se qualcosa è un anti-modello nel tuo caso.

La linter non è a conoscenza del fatto che usi una classe come mixin. Pylint è consapevole del fatto che usi un mixin se aggiungi il suffisso 'mixin' o 'Mixin' alla fine del nome della classe, quindi la linter smette di lamentarsi.

I mixin non sono cattivi o buoni di per sé, sono solo uno strumento. Li fai un buon uso o un cattivo uso.

I mixin sono ok?

I mixin Python sono un anti-pattern?

I mixin non sono scoraggiati: sono un buon caso d'uso per l'ereditarietà multipla.

Perché la tua linter si lamenta?

Pylint si sta ovviamente lamentando perché non sa da dove otherfuncviene stack, e my_var proviene.

Banale?

Non vi è alcuna ragione immediatamente apparente per separare questi due metodi in classi genitore separate, sia nel tuo esempio nella domanda, sia nel tuo esempio più banale collegato, mostrato qui.

201
202 class OpCore():
203     # nothing runs without these
204
205 class OpLogik(): 
206     # logic methods... 
207 
208 class OpString(): 
209     # string things
210 
211 
212 class Stack(OpCore, OpLogik, OpString): 
213 
214     "the mixin mixer of the above mixins" 

Costi di mixin e rumore

Il costo di ciò che stai facendo è rendere rumoroso il tuo linter. Quel rumore potrebbe oscurare problemi più importanti con il tuo codice. Questo è un costo importante da pesare. Un altro costo è che stai separando il tuo codice correlato in spazi di nomi diversi che potrebbe rendere più difficile per i programmatori scoprire il significato di.

Conclusione

L'ereditarietà consente il riutilizzo del codice. Se ottieni il riutilizzo del codice con i tuoi mixin, fantastico, hanno creato valore per te che probabilmente supera i possibili altri costi. Se non stai ottenendo il riutilizzo / deduplicazione del codice di righe di codice, probabilmente non stai ottenendo molto valore per i tuoi mixin e, a quel punto, penso che il costo del rumore sia maggiore dei vantaggi.