On Thu, Feb 3, 2011 at 4:47 PM, Jari Pennanen <[email protected]> wrote: > "Meh - this seems like reinventing a syntactic wheel to me. Python > 2.6 > has class decorators." - Russel
The pair of Ls in my email address aren't just there for show. Russell. Two Ls. > Why to use decorators? They cannot be overridden neatly in subclasses, > see my above gist about this subclassing. Why use decorators? Because they're an established pattern. They're conceptually well aligned -- take this existing thing, and wrap it with this extra logic. And using decorators for this purpose is a usage that already has precedent for exactly this purpose with function-based views. The catch is that it isn't easy to build a decorator that does what we need it to do. My problem with the approach you're describing is that I don't see that it has precedent. Part of good API design is that it isn't surprising. Why is a randomly named class variable the right place to define the list of decorators that will be invoked before a dispatch? What analogs exist in Django, or the wider Python community, that would point to changing behavior based upon the value stored in a class variable. To my mind, this isn't quite the same as setting template_name. That's a simple configuration issue, not something that fundamentally alters view behavior. To reinforce the point -- as an alternative to specifying template_name, you can override the function get_template_names() which programatically returns the right template. It would strike me as strange for the list of decorators to be applied to a view to be configured in the same way. Yet it would be contradictory to have some class variables extendable by function, but not others. I'm not saying I have a a better alternative waiting to be used -- I'm just letting you know why I feel a design decision is required. Yours, Russ Magee %-) -- 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.
