xonix Oct 4 2009 at 19:42

(Python) Парочка полезных декораторов

3 min

1.1K

Lumber room

+16

Comments 15

farcaller Oct 4 2009 at 19:56

Красиво, да. Но если к каждой рабочей функции цеплять тесты, то у нее появиться существенный оверхед, не так ли?

xonix Oct 4 2009 at 19:59

Абсолютно нет! ) Заметьте:

def decor(f):

    check(f)

    return f

Декоратор возвращает функцию неизменной! Т.е. оверхед будет только на запуске на прогонку тест-кейсов. Дальше код будет работать с прежней скоростью.

kmike Oct 4 2009 at 22:16

Но до того, как возвратить, тестирует. Т.е. оверхед будет не при запуске на прогонку тест-кейсов, а при импорте. Ну или, если угодно, запуск на прогонку будет при импорте, в отличии от обычных доктестов и юнит-тестов, которые выполняются по требованию.

Иногда это вполне допустимо, но как универсальное решение — не катит точно. Универсальное решение с похожим подходом и без оверхеда — обычные доктесты.

xonix Oct 4 2009 at 22:22

Протестовать не буду, тут все верно. На универсальность не разу не претендовал, ибо.

По поводу «оверхед будет не при запуске на прогонку тест-кейсов, а при импорте» при желании можно сообразить что-то типа

import should

should.not_check() # отменяет тесты.

Пост писался не только для практической пользы, сколько еще для того, что может оказаться кому-то полезным примером в написании декораторов.

cleg Oct 4 2009 at 20:18

BDD в Python стиле.
очень хорошо, спасибо.
я бы еще добавил should.not_throw_anything()
и как-то в таком стиле бы еще сделать инвариантность…

xonix Oct 4 2009 at 20:20

да, пространство для расширения большое =) Просто спонтанно написал вышеприведенный код, решая задачки из projecteuler

glader Oct 4 2009 at 20:58

Идея красивая. Но имхо код загромождается. Я за то, чтобы хранить тест-кейсы в отдельном месте.

keymone Oct 4 2009 at 21:53

засорять код тестами считается «полезно»?

xonix Oct 4 2009 at 21:59

не согласен со словом «засорять», по-этому считаю вопрос бессмысленным. Вы же, например, не станете протестовать против «засорения» кода Javadoc'ами? Так что плохого в таком подходе?

keymone Oct 4 2009 at 22:17

против «засорения» жавадоками конечно протестовать буду. все в файле должно помогать тому, кто решил в нем разобраться. конвенции — помогают, документация — помогает, тесты — сомнительно… поэтому — мусор.

funca Oct 4 2009 at 22:19

формально, это не тесты, а утверждения. На месте автора, я бы еще поиграл с читабельностью этого кода.

@should.throw((1,0), Exception)
@should.give((5,2),7)

например так:

@should.throw(Exception).when(1,0)

@should.give(7).when(5,2)

но думаю, есть лучшие варианты.

xonix Oct 4 2009 at 22:25

Были мысли, но остановился на более простом в реализации варианте, пусть менее выразительном…
А вообще, да, можно и так сообразить )

eXod Oct 4 2009 at 22:34

С python'ом знаком недавно. К сожалению не понял, а чем предлагаемый вариант лучше doc-текстов? К томуже доктесты — это еще и автоматическая документация =) Да и возможностей (из коробки) у доктестов значительно больше.

barbuza Oct 5 2009 at 01:08

доктест понятнее

def div(a, b):
    """
    >>> div(1, 0)
    Traceback (most recent call last):
        ...
    ZeroDivisionError: integer division or modulo by zero
    """
    return a / b

def add(a, b):
    """
    >>> add(5, 2)
    7
    >>> add('aa', 'bbb')
    'aabbb'
    >>> add([1], [2, 3])
    [1, 2, 3]
    """
    return a + b

obenjiro Oct 5 2009 at 05:24

>> Тем кто не знаком с декораторами — ссылка для ознакомления.

Как меня замучали «умники»… Уже просто в печенках сидит…
— О смотрите, я знаю что такое Гугл и я могу вас туда послать… Ух какой я умный!

PS: А за сам пост и интересный декоратор спасибо :)