-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My comments:
The class-decorator support isn't really universal, it's specific to Django's built-in class-based views. This would need to be well-documented, and the decorator should also probably check for the existence of a "dispatch" method and say "sorry, don't know how to decorate this class" if it's not there. (Could also check issubclass(View) but that would prevent use with API-compatible CBVs not descended from Django's base View). I don't much like seeing an isinstance(HttpRequest) check introduced (for the first time) as an implicit constraint on what can be passed to a view. I think this is likely to break view tests in the wild using non-HttpRequest-descended dummy requests (just like the test that fails in Django). I don't think there's any good reason to call such tests "broken" and make people change them, besides the desire to implement this patch. More generally, the isinstance() requirement doesn't feel very Pythonic. Personally I think that the documented status quo for decorating CBVs is adequate, if not ideal. The rundown here didn't mention the "login_required(MyView.as_view())" approach that works in many, if not most, cases and is simple, non-magical, and non-ugly (it also isn't restricted to urls.py, you can just as easily do it in views.py right under the class definition). I would be in favor of updating the docs to recommend this approach even more strongly, showing more advanced usage with decorator-factories (e.g. user_passes_test), and recommending the method-decorator alternative only in the case where you want to decorate a CBV and then subclass it (the wording in the current docs about decorating "all instances" assumes that the as_view() approach can only be used in urls.py). Regardless of whether its a magical all-in-one decorator-decorator like that proposed here, or something like class_view_decorator, IMO all of the proposed approaches for class decoration on #14512 have serious enough downsides that we're better off with the status quo. Carl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5zTk0ACgkQ8W4rlRKtE2dhtQCg4GbN/Vht7KTZFiqMQsqvmt1/ VB8AoI69o+NHNnceR5q9p8kzC9BaNJ87 =2rSD -----END PGP SIGNATURE----- -- 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.
