Korzystanie z Design by Contract w Python

Question

Szukam zacząć używać DBC na wielu projektach opartych na Pythonie w pracy i zastanawiam się, jakie doświadczenia mieli z tym inni. Do tej pory moje badania okazało się, co następuje:

• http://www.python.org/dev/peps/pep-0316/ - PEP 316, która ma na celu standaryzację programowanie kontraktowe dla Pythona, który został odroczony. Ta PEP sugeruje użycie docstruktów.
• http://www.wayforward.net/pycontract/ - Umowy na język Python. Wydaje się, że jest to kompletne, ale nieobsługiwane środowisko przy użyciu docstruktów.
• http://www.nongnu.org/pydbc/ - PyDBC realizujący kontrakty przy użyciu metaclasses. Też nieużywane przez kilka lat.

Moje pytania to: czy użyłeś DBC z Pythonem do dojrzałego kodu produkcyjnego? Jak dobrze to działało/czy było warte wysiłku? Jakie narzędzia poleciłbyś?

Answer 1

Nie używałam projektu na podstawie umowy w Pythonie, więc nie mogę odpowiedzieć na wszystkie twoje pytania. Spędziłem jednak trochę czasu, przeglądając bibliotekę contracts, której najnowsza wersja została niedawno wydana i wygląda całkiem nieźle.

Było kilka dyskusji na temat tej biblioteki w reddit.

Answer 2

PEP, który znalazłeś, nie został jeszcze zaakceptowany, więc nie ma standardowego ani akceptowanego sposobu, aby to zrobić (jednak - zawsze możesz wdrożyć PEP samemu!). Istnieje jednak kilka różnych podejść, jak już zauważyłeś.

Prawdopodobnie najbardziej lekka jest po prostu użycie dekoratorów Python. W zestawie Python Decorator Library znajduje się zestaw dekoratorów do warunków wstępnych/końcowych, które są dość proste w użyciu. Oto przykład z tej strony:

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

Teraz wspomnisz o niezmiennikach klas. Są nieco trudniejsze, ale sposób, w jaki bym to robił, to zdefiniowanie opcji sprawdzania niezmiennika, a następnie skorzystanie z funkcji podobnej do dekoratora post-condition, która jest niezmienna na końcu każdego wywołania metody. Jako pierwsze cięcie prawdopodobnie mógłbyś po prostu użyć dekoratora pokwitowań, tak jak jest.

Answer 3

Chociaż nie jest to dokładnie projekt według umowy, niektóre ramy testowe sprzyjają testowaniu właściwości są bardzo zbliżone koncepcyjnie.

randomizowane badanie na razie pewne właściwości trzymać w czasie pracy pozwala łatwo sprawdzić:

• niezmienniki
• domeny wartości wejściowych i wyjściowych
• inne przed- i postconditions

dla Pythona istnieje kilka frameworków testowych w stylu QuickCheck:

• paycheck
• qc

Answer 4

Z mojego doświadczenia design-by-umowy jest warte zrobienia, nawet bez wsparcia językowego.W przypadku metod, które nie są przesłonięte asercje, wraz z docstrings są wystarczające zarówno dla warunków wstępnych i post. W przypadku nadpisywanych metod dzielimy metodę na dwie: metodę publiczną, która sprawdza warunki przed i po, oraz metodę chronioną, która zapewnia implementację, i może być nadpisana przez podklasy. Oto przykład tego ostatniego:

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

mam pierwiastkowania jako ogólny przykład wzornictwa-by-umowy z epizodu na design-by-umowy w radiu oprogramowania inżynierskiego (http://www.se-radio.net/2007/03/episode-51-design-by-contract/). Wspomnieli również o potrzebie wsparcia językowego, ponieważ twierdzenia nie były pomocne w zapewnieniu zasady substytucji Liskova, chociaż mój przykład powyżej ma na celu wykazanie, że jest inaczej. Powinienem również wspomnieć o idiomie C++ pimpl (implementacja prywatna) jako źródle inspiracji, choć ma on zupełnie inny cel.

W mojej pracy niedawno refaktoryzowałem ten rodzaj sprawdzania kontraktów w większej hierarchii klas (umowa była już udokumentowana, ale nie została systematycznie przetestowana). Istniejące testy jednostkowe wykazały, że umowy były wielokrotnie naruszane. Mogę tylko dojść do wniosku, że powinno to być zrobione dawno temu, a zakres testów jednostkowych opłaca się jeszcze bardziej, gdy zastosuje się projekt na podstawie umowy. Oczekuję, że każdy, kto spróbuje tej kombinacji technik, wykona te same obserwacje.

Lepsze wsparcie narzędziowe może zaoferować nam jeszcze większą moc w przyszłości, z zadowoleniem przyjmuję to.