Existing in python != pythonic. (not stating that class decorators aren't pythonic, but that argument is flawed)
Just watched the video my thoughts regarding it, and this discussion. The Augment pattern is a terrible use case for class decorators when you are just overriding methods. It's nothing more then Mixins with a different syntax, for no reason that I can determine other then someone not liking the way declaring a mixin looks, functionally you are still mixing in. What benefit do you get from hiding the fact you are really just doing a Mixin? With the code Jacob posted there is… 16? (My math might be wrong) different permutations of code flow just to support universal decorators. The order would matter in the sense that any mixins would have to come before the base view class, so: class ProtectedView(LoginRequired, View) is valid but class ProtectedView(View, LoginRequired) is not. But this is just python, there's nothing magical about object inheritance and in python object inheritance is left to right. Additionally, as I just thought, there is a way to satisfy both camps. The support code I proposed to allow @login_required with Mixins to still work with function based views could include the universal decorator approach that Jacob included. That would be a change so that the actual "is this a user, are they logged in etc" logic would live in a class that could be mixed in, then the support code for functions would use that class and wrap the test portions around the function view, and then the universal decorator code could just do the Augment pattern. All camps == Happy? People who prefer mixins can mixin, people who prefer @decorators can decorate, everything is supported from one code base. On Friday, September 16, 2011 at 1:45 PM, Roald de Vries wrote: > On Sep 16, 2011, at 6:19 PM, Donald Stufft wrote: > > > Documentation is being worked on, and is orthogonal to the current > > discussion of how > > to handle things like requiring logins with the new CBVs. > > I just watched "Class Decorators: Radically Simple" by Jack Diederich, > who wrote the class decorators PEP, and I think it's very useful to > watch (25 min.) for this discussion. According to him it is good > practice to return the class that is decorated, which I think we > should follow, and which solves the biggest practical problems with > decorating. Moreover, the fact that class decorators exist indicate > that they are pythonic. So +1 for the decorators. > > Considering the mixins: IMHO, the order of base classes shouldn't > matter. Can this be satisfied by the mixin-approach? > > @Carl Meyer: I would opt for applying decorators *in* the class, so > you can still derive from it. Like:: > > class MyView(View): > @classonlymethod > def as_view(cls, *args, **kwargs): > return login_required(super(MyView, cls).as_view(*args, > **kwargs)) > > Cheers, Roald > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
