Как реализовать декоратор класса в python?

Question

[Валентин]

Вопрос знатокам python.
Исходная задача - необходимо, чтобы один из методов класса оборачивался в декораторы. Это можно сделать через переопределение этого метода и оборачиванием его через method_decorator.

class MyView(View):
   @method_decorator(login_required):
   def dispatch(self, *args, **kwargs):
       return super(MyView, self).dispatch(*args, **kwargs)

Я не хочу переписывать каждый раз этот метод. Мне кажется более логичным такое решение

@viewdecorator(login_required)
class MyView(View):
    pass

Вот вопрос - как написать viewdecorator?

Сейчас я написал следующее:

def viewdecorator(decorator):
    def wrap(cls):
        dispatch = getattr(cls, 'dispatch', None)
        if dispatch:
            setattr(cls, 'dispatch', method_decorator(decorator))
        return cls
    return wrap

При этом почему-то не переносятся classmethod-ы и classonlymethod-ы. Конкретно в моем случае не идет as_view().
Как сделать так, чтоб это перенеслось?

Answer 1

[Валентин]

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

def viewdecorator(decorator):
    def wrap(cls):
        getattribute = cls.__getattribute__

        def newgetattr(cls, name):
            attr = getattribute(cls, name)
            if name == 'dispatch':
                return decorator(method_decorator(attr))
            return attr 

        cls.__getattribute__ = newgetattr
        return cls
    return wrap

@viewdecorator(login_required)
@viewdecorator(csrf_exempt)
class EntriesMyList(EntriesList):
    template_name = 'index.html'

Comments

[Алексей Букин]

Ну не могу я не предложить свой вариант реализации =)

def apply_decorator(decorator):

    def wrap(cls):

        class OverrideClass(cls):

            @method_decorator(decorator)
            def dispatch(self, *args, **kwargs):
                return super(OverrideClass, self).dispatch(*args, **kwargs)

        return OverrideClass

    return wrap


@apply_decorator(login_required)
class ProfileUpdateView(UpdateView):

[Валентин]

@abukin безусловно этот вариант работает, но вам возвращается новый класс. Это дает то, что нужно помимо создания копировать еще и метаинформацию (doc, тесты, названия).
И если для декорирования функций в functools есть wraps, то для классов придется написать его самому.
И еще я заметил, возможно логичнее будет декорировать as_view, а не dispatch

[Алексей Букин]

@vvpoloskin Ну этот вариант покрайне мере создает обьект класса 1 раз для вюхи. В вашем же случае функция newgetattr выполнялись чуть ли не 3 раза т.к. от джанги шло обращение к разным методам через getattribute же до того как вызвался dispatch.

Скопировать метоинформацию в классе достаточно просто. Но тут как раз тот случай когда гибкость перекрываестся красотой и приходится выбирать либо гибкость либо красота. Я бы выбрал второе. =)

class OverrideClass(cls):
    __doc__ = cls.__doc__
    __name__ = cls.__name__

    @method_decorator(decorator)
    ...

Лучше декорировать тот метод который принято декорировать в Python (Django) в опрееленных случаях. Метод dispatch специально существует для таких случаев чтобы предупредить или сделать чтолибо до выполнения остальной части вьюхи. Другим ведь программистам ваш код читать придется когда то. Ещё проще и понятнее обернуть в функцию вьюху непосредственно в urls.py без лишних телодвижений.

[Валентин]

@abukin ваш код более наглядный и красивый, но...

sys.getsizeof(View)
452
sys.getsizeof(View.__getattribute__)
40

В конечном итоге, какая разница, вызывается мой новый метод три раза или метод вашего нового класса)

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

Еще замечание на счет метаинформации - да, вы переопределии такие мелочи, как __doc__, __name__. Но вот для сходства еще надо менять mro и bases (а может еще и __subclasshook__?)

[Алексей Букин]

@vvpoloskin Непонимаю зачем вы показали размер создаваемого обьекта в памяти? Это не на что не будет влиять темболее на быстроту. Сейчас на машинах гигабайты памяти. А вот ненужный вызов функции по сравнению с размерностью замедлит ровно в *n раз.

Какое выбрашенное исключение? Там не должно быть никаких исключений это обычное наследование с перезаписью метода базового класса только выполненное через декоратор. Кстати программисты постоянно видят исключения т.к. ничего не должно замалчиваться и это нормально.

Зачем вам копировать bases? Какая в этом потребность? У вас простое наследование. Все базовые классы и так создались в нужном порядке. В итоге к классу вьюхе просто добавится в начало определения базовых классов ещё один базовый класс OverrideClass а mro это просто функция которая отображает базовые классы.

Answer 2

[Алексей Букин]

class LoginRequiredMixin(View):

    @method_decorator(login_required)
    def dispatch(self, *args, **kwargs):
        return super(LoginRequiredMixin, self).dispatch(*args, **kwargs)

И от этого класса наследуете все свои порожденные вьюхи.
Например:

class ProfileUpdateView(LoginRequiredMixin, UpdateView):
...

Только следите за тем чтобы LoginRequiredMixin был первым базовым классом. Т.к первым делом будет вызываться его dispatch а потом уже все остальные, если пройдут проверку.

Comments

[Валентин]

Представим, что мне нужно продекорировать различными методами - login_required, json_response, csrf_exempt, да мало ли чего. Кроме того, classbasedviews подразумевает активное использование миксинов. Вы будете делать целую простыню родителей класса?
Я же спросил общий вопрос - как написать декоратор класса и что делать с class-методами. Это вообще может быть не django.

[Алексей Букин]

Частные случаи можно и в потомках тем же декоратором реализовать. А вообще да если нужна гибкость и проект из кучи разных вьюх где идет переключение функционала. Не вижу никакой проблемы написать 3 разных миксина и по своей нужде их наследовать можно даже в отдельном приложении. Это не простыня а явное обозначение желаемого в действительное. Ибо "Явное лучше, чем неявное. Простое лучше, чем сложное."

И вообще если у вас может быть не django какой там может быть dispatch? Это всеголиш метод класса Generic Base View джанговский.

Answer 3

[Алексей]

Если всё правильно понял, то вам поможет эта статья.

Comments

[Валентин]

Хорошо, они сами добавляют as_view. Но почему он не переходит в рамках наследования? Получается высе классовые методы надо явно переносить?

Answer 4

[Rrooom]

Может не будете костылить? А используете наследование?
Еще в urls.py можно обернуть вьюху login_requireдом. Тоже частая метода.

Comments

[Валентин]

Почему костылить? Это нормальный вариант, просто пока нигде решения не написано.
С наследованием мне не очень удобно - есть куча вьюх, тупо различающихся правами доступа и queryset-ами.

[Rrooom]

@vvpoloskin Вот такие надстройки - неудобно. А множественное наследование и фабрики классов (в то числе динамических) позволяют очень красиво и гибко разрулить все права доступа.

[Валентин]

@Rrooom не в моем случае, у меня уже нехилая цепочка классов для наследования. Кроме того, при наследовании не получится миксовать ограничения от разных классов - dispatch будет браться только от одного из цепочки.

[Rrooom]

@vvpoloskin С чего это? super не забывайте и вся цепочка проверится.

Answer 5

[Вита Адучиев]

Как мне декорировать функцию (метод) внутри класса?

class Example:
    def func(self, f):
        # что-то делает
        f()
        return 'decorate'
     @func
     def f1(self)