On 7/21/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: >... If you have to use @somegeneric.before and > @somegeneric.after, you can't decide on your own to add > @somegeneric.debug.
> However, if it's @before(somegeneric...), then you can add > @debug and @authorize and @discount and whatever else > you need for your > application, without needing to monkeypatch them in. I honestly don't see any difference here. @somegeneric.method implies that somegeneric is an existing object, and even that it already has rules for combining .before and .after; it can just as easily have a rule for combining arbitrary methods. If you're saying that @discount could include its own combination rules, then each method needs to repeat the boilerplate to pick apart the current decision tree. The only compensating "advantage" I see is that the decision tree could be changed arbitrarily from anywhere, even as "good practice." (Since my new @thumpit decorator would takes the generic as an argument, you won't see the name of the generic in my file; you might never see it there was iteration involved.) > Our brains run by pattern recognition, with more-specific > patterns taking precedence, so this is an easier model for your > brain to follow than step-by-step computation anyway. Only if you are confident that you have all the patterns enumerated. I realize that subclasses are theoretically just as arbitrary, but they aren't in practice. Base classes are almost always named directly, rather than indirectly through a variable. Subclassing (normally) affects only the first dimension, so you don't have a cartesian product to mentally resolve. You can certainly say now that configuration specialization should be in one place, and that dispatching on parameter patterns like (* # ignored , :int # actual int subclass , :Container # meets the Container ABC , 4<val<17.3 # value-specific rule ) is a bad idea -- but whenever I look at an application from the outside, well-organized configuration data is a rare exception. > At 10:55 PM 7/20/2007 -0700, Talin wrote: > >If it turns out that there's no way to get a callback when the > >class has finished being built, Could you clarify why the __class__ attribute being used by super is not sufficient? -jJ _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
