Le classi Mixin sono classi astratte di base

Question

Le classi di missaggio sono classi di base astratte? Nell'esempio seguente, le chiamate a test_base fallirebbero perché python non sarebbe in grado di risolvere self.assertEqual per esempio.

Inoltre, PyCharm è errato come segnalazione Le classi Mixin come quella di seguito hanno errori di attributo non risolti?

class TestConverterMixin(object): 
    def setUp(self): 
     self.alt_hasher = getattr(hash, self.converter.__class__.__name__) 

    def test_base(self): 
     with self.settings(PASSWORD_HASHERS=[self.hasher, ]): 
      load_hashers(settings.PASSWORD_HASHERS) 

      for password in PASSWORDS: 
       orig = self.alt_hasher.encrypt(password) 
       conv = self.converter.from_orig(orig) 

       # see if we get a working hash: 
       self.assertTrue(check_password(password, conv)) 

       # convert back and test with passlib: 
       back = self.converter.to_orig(conv) 
       self.assertEqual(orig, back) 

Answer 1

Le classi di missaggio sono AbstractBaseClasses? La risposta più accurata per il tuo caso non è, ma probabilmente dovrebbe essere.

La tua classe da sola non può sopravvivere per le ragioni che hai indicato. Rendendo un ABC dici esplicitamente chiunque guardando la classe (come PyCharm) che

from abc import ABCMeta, abstractmethod 

class TestConverterMixin(object): 
    __metaclass__ = ABCMeta 

    @abstractmethod 
    def assertEqual(self, other): 
     "Need concrete implementation somewhere" 

    .... the rest of your code 

Il problema è che si avrebbe bisogno di questo per tutti gli altri metodi (self.AssertTrue, self.converter ecc). Potresti avere qualcos'altro in mente ma questo mi sembra seriamente solo una sottoclasse di unittest.TestCase per me.

Oh ed è stato PyCharm sbagliato. No, hanno capito bene. Se l'hai fatto un ABC o una sottoclasse di TestCase, non si sarebbero lamentati. Se hai usato le interfacce, come zope.Interface, pycharm e simili di solito si sbagliano visto che non capiscono il processo di registrazione e ricerca (è fuori dal core python)

Answer 2

Continuavo ad avere problemi per far funzionare PyCharm non lamentarsi di errori di riferimento di attributo irrisolti sulle classi di mixin. In particolare, ho anche avuto lezioni di mixin basate su altre classi di mixin per le quali non potevo farne ereditare l'una dall'altra. Ma poi ho trovato questo modo quasi perfetto per fare PyCharm 2.017,1 felice:

class Human: 
    def is_male(self): 
     return True 

class BeardMixin: 
    _facial_hair = {'length': 7, 'color': 'brown'} 

    def has_beard(self): 
     return True 

class BeardLengthMixin: 
    """Mixin for class Human with BeardMixin to provide get_beard_length()""" 

    def get_beard_length(self): 
     assert isinstance(self, (Human, BeardMixin)) 
     # PyCharm will now not complain about any of these 3 attributes 
     if self.is_male() and self.has_beard(): 
      return self._facial_hair['length'] 

L'istruzione assert dà PyCharm le informazioni necessarie su quali tipi di auto potrebbe essere. C'è però un inconveniente: la stessa affermazione non fa quello che pensi che faccia: controlla solo che il sé sia ​​di entrambi i tipi, non se sia di entrambi. Sfortunatamente, l'uso di due affermazioni di asser non funziona, perché il secondo sovrascrive il primo per quanto riguarda la deduzione del tipo di PyCharm.