[Python-3000] pep 3124 plans (original) (raw)

Jim Jewett jimjjewett at gmail.com
Mon Jul 30 20:20:14 CEST 2007

On 7/21/07, Phillip J. Eby <pje at telecommunity.com> 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

More information about the Python-3000 mailing list