Quelle est votre convention pour distinguer entre les méthodes objet appelées par l'extérieur et les méthodes objet appelées par une sous-classe?

Question

Je connais la plupart des tenants et aboutissants de l'approche de Python pour les variables privées/membres/fonctions/...

Cependant, je n'arrive pas à faire la distinction entre les méthodes d'utilisation externe et les sous-classes. .

Prenons l'exemple suivant:

class EventMixin(object): 
    def subscribe(self, **kwargs): 
     '''kwargs should be a dict of event -> callable, to be specialized in the subclass''' 

    def event(self, name, *args, **kwargs): 
     ... 

    def _somePrivateMethod(self): 
     ... 

Dans cet exemple, je veux préciser que souscrire est une méthode à utiliser par les utilisateurs externes de la classe/objet, alors que l'événement est une méthode qui devrait ne pas être appelé de l'extérieur, mais plutôt par des implémentations de sous-classes.

À l'heure actuelle, je considère les deux parties de l'API publique, par conséquent n'utilisez pas de traits de soulignement. Toutefois, pour cette situation particulière, il serait plus simple d'utiliser, par exemple, aucun caractère de soulignement pour l'API externe, un trait de soulignement pour l'API sous-classifiable et deux caractères de soulignement pour l'API privée/interne. Cependant, cela deviendrait difficile à manier car alors l'API interne aurait besoin d'être invoquée comme

self._EventMixin__somePrivateMethod() 

Alors, quelles sont vos conventions, de codage sage, documentationwise, ou autrement?

Answer 1

use no underscores for the external API, 
one underscore for the subclassable API, 
and two underscores for the private/internal API 

Ceci est une façon raisonnable et relativement courante de le faire, oui. Le double soulignement-pour-réellement-privé (par opposition à «protégé» en termes de C++) est en pratique assez rare. Vous ne savez jamais vraiment quels comportements une sous-classe pourrait vouloir remplacer, donc supposer «protégé» est généralement un bon pari à moins qu'il y ait une bonne raison pour laquelle déconner avec un membre peut être particulièrement dangereux. Non, vous pouvez simplement utiliser la version double-soulignée et elle sera automatiquement munie. C'est moche mais ça marche.

Answer 2

En règle générale, j'utilise le double __ pour avoir plus de problèmes, car cela rend les tests unitaires très douloureux. l'utilisation de single _ comme convention pour les méthodes/attributs qui ne sont pas destinés à faire partie de l'interface publique d'une classe/module particulier est mon approche préférée.

Answer 3

Je voudrais faire la suggestion que lorsque vous rencontrez ce genre de distinction, il peut être judicieux d'envisager d'utiliser la composition au lieu de l'héritage; en d'autres termes, instancier EventMixin (probablement le nom changerait) au lieu de l'hériter.