Hello, On 5/3/07, Shannon -jj Behrens <[EMAIL PROTECTED]> wrote: > > > There is a caveat in using methods like __before__. The base class' > > implementation needs to be called explicitly (as with any super impl). > Which > > means putting "common" logic into BaseController.__before__ poses the > threat > > that subclass may failed to execute it. > > > > I am interested in hearing how others deal with this issue. I ended up > > having an empty __before__ in BaseController, putting "common" logic > into > > BaseController.__call__ and never overriding __call__ in subclasses. > > I don't have this problem, but I see where you're coming from. Just > shoving stuff in BaseController.__call__ does make sense. If you > really want to *force* the user to call BaseController's __before__ > and __after__ methods, throw some assertion statements into > BaseController's __call__ method: > > assert getattr(self, "_base_controller_before_called", False), \ > "Dummy, you forgot to call BaseController.__before__!" > > Then, in BaseController's __before__ method, you just make sure to set > that attribute.
I think Ben said __call__ is called earlier than __before__. Which means it won't work. I find that using assertions in this way is a great way to keep > subclasses "honest" ;) It's good policy to put assertions in places > where you know the user is likely to mess up. Right. Asserts are very helpful. And easier to type then if ...: raise RuntimeError Max. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
