On 4 November 2010 22:30, David Cramer <[email protected]> wrote: > Agree with Alex. We're considering moving more towards decorating > views rather than class attributes. I'm not sure of the performance > implications of many classes vs decorating functions on a large class > instead, but it just seems to make more sense in some cases.
What exactly do you mean by "decorating views" in this context ? > On Thu, Nov 4, 2010 at 2:26 PM, Alex Gaynor <[email protected]> wrote: >> >> Well, there's no reason the decorator couldn't be used as a class >> decorator (on 2.6 and above). I'll admit that the settings attribute >> on TestCase is more consistant with how we've handled other things >> (urls, fixtures), however, for whatever reason I'm not a fan, as it >> forces you to split up tests that should logically be grouped on a >> single class. You can alter the setting both with a class attribute/decorator and then alter it some more for a particular test. For example (excuse the horrible naming): @alter_class_settings(USE_L10N=True, OTHER_SETTING=False): class MyTest(TestCase): # 20 tests that rely on L10N @alter_test_settings(USE_L10N=False) def test_no_localization(self): pass I meant the class-level decorator/attribute as a shortcut for a common case. I agree that splitting tests just because of settings is bad, but repeating the same decorator all over the test case is bad too, imho. Here[1] is an implementation of a context manager and a class decorator based on the function decorator that David provided. Does it look reasonable ? [1]: https://gist.github.com/663367 -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
