Utilisation de Design by Contract en Python

Question

Je suis à la recherche pour commencer à utiliser DBC sur un grand nombre de Python projets au travail et je me demande ce que les autres expériences ont eu avec elle. Pour l'instant, mes recherches sont les suivants:

• http://www.python.org/dev/peps/pep-0316/ - PEP 316 qui est censé standardiser la conception par contrat pour Python qui a été reporté. Ce PEP suggère d'utiliser des docstrings.
• http://www.wayforward.net/pycontract/ - les Contrats de Python. Cela semble être complète, mais non maintenus cadre à l'aide d'docstrings.
• http://www.nongnu.org/pydbc/ - PyDBC qui met en œuvre des contrats à l'aide de metaclasses. Aussi laissés à l'abandon pendant quelques années.

Mes questions sont les suivantes: avez-vous utilisé DBC avec Python pour la maturité de la production de code? Comment il fonctionne/est-il encore la peine? Quels sont les outils que vous recommanderiez?

Answer 1

Le PEP-vous trouvé n'a pas encore été accepté, donc il n'y a pas un standard ou la façon de le faire (pour l'instant, vous pouvez toujours mettre en œuvre du PPE-tse-vous!). Cependant, il existe quelques façons différentes, comme vous l'avez trouvé.

Probablement le plus de poids léger, est de simplement utiliser Python décorateurs. Il y a un ensemble de décorateurs pour la pré-/post-conditions le Python Décorateur de la Bibliothèque qui sont assez simple à utiliser. Voici un exemple de cette page:

  >>> def in_ge20(inval):
  ...    assert inval >= 20, 'Input value < 20'
  ...
  >>> def out_lt30(retval, inval):
  ...    assert retval < 30, 'Return value >= 30'
  ...
  >>> @precondition(in_ge20)
  ... @postcondition(out_lt30)
  ... def inc(value):
  ...   return value + 1
  ...
  >>> inc(5)
  Traceback (most recent call last):
    ...
  AssertionError: Input value < 20

Maintenant, vous mentionnez classe d'invariants. Ce sont un peu plus difficile, mais la façon dont je voudrais faire est de définir un callable pour vérifier l'invariant, alors avoir quelque chose comme la post-condition décorateur vérifier que invariant à la fin de chaque appel de méthode. En tant que première coupe vous pourriez probablement utiliser simplement la postcondition décorateur comme-est.

Answer 2

Dans mon expérience, la conception par contrat vaut la peine de faire, même sans le support de la langue. Pour les méthodes qui ne sont pas remplacées assertions, avec docstrings sont suffisante pour à la fois pré - et postconditions. Pour les méthodes qui sont remplacées, nous avons divisé la méthode en deux: une méthode publique qui, vérifiez les pré - et post-conditions, et une méthode protégée qui prévoit la mise en œuvre, et peuvent être remplacées par des sous-classes. Voici un exemple de ce dernier:

class Math:
    def square_root(self, number)
        """
        Calculate the square-root of C{number}

        @precondition: C{number >= 0}

        @postcondition: C{abs(result * result - number) < 0.01}
        """
        assert number >= 0
        result = self._square_root(number)
        assert abs(result * result - number) < 0.01
        return result

    def _square_root(self, number):
        """
        Abstract method for implementing L{square_root()}
        """
        raise NotImplementedError()

J'ai eu la racine carrée d'exemple général de la conception par contrat à partir d'un épisode sur la conception par contrat du logiciel d'ingénierie radio (http://www.se-radio.net/2007/03/episode-51-design-by-contract/). Ils ont également mentionné le besoin de soutien de la langue parce que les affirmations n'étaient pas utiles pour assurer le Liskov substitution principe, bien que mon exemple ci-dessus vise à démontrer le contraire. Je devrais aussi mentionner que le C++ pimpl (privé la mise en œuvre) de l'idiome comme une source d'inspiration, même si ça a un tout autre but.

Dans mon travail, j'ai récemment refait ce genre de contrat et de vérification dans une classe plus large de la hiérarchie (le contrat a déjà été documentée, mais pas systématiquement testés). Unité existante-des tests ont révélé que le contrat a été violé à de multiples reprises. Je ne peux que conclure de ce qui aurait dû être fait il y a longtemps, et que l'unité de la couverture de test paye même plus d'une fois la conception par contrat est appliqué. J'attends quelqu'un qui essaie de sortir de cette combinaison de techniques pour faire les mêmes observations.

Meilleur outil de soutien peut nous offrir encore plus de puissance à l'avenir, je souhaite la bienvenue à cela.

Answer 3

Je n'ai pas utilisé la conception par contrat en python, je ne peux donc pas répondre à toutes vos questions. Cependant, j'ai passé un certain temps à regarder la bibliothèque de contrats , dont la dernière version a été publiée récemment, et elle est très jolie.

Il y a eu des discussions à propos de cette bibliothèque dans Reddit .

Answer 4

Bien que pas exactement de la conception par contrat, à des tests de cadres faveur de la propriété de l'approche des tests sont très proches sur le plan conceptuel.

Test aléatoire pour si certaines propriétés tenir dans runtime permet de vérifier facilement:

• les invariants
• les domaines d'entrée et de sortie des valeurs de
• d'autres pré - et postconditions

Pour Python il y a quelques QuickCheck de style infrastructures de test:

• chèque de règlement
• qc