On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 08:29 AM 5/14/2007 -0700, Guido van Rossum wrote: > >On 5/14/07, Paul Moore <[EMAIL PROTECTED]> wrote: > > > However, it looks like > > > there's a general feeling emerging that snipping certain sections > > > would be enough. I'd agree with that - my personal feeling is that > > > it'd be OK to remove all of the following sections: > > > > > > * "Before" and "After" Methods (as per Steven Bethard's suggestion) > > > * "Around" Methods (as per Steven Bethard's suggestion) > > > * Custom Combinations (as per Steven Bethard's suggestion) > > > * Interfaces and Adaptation (doesn't feel like a core aspect of > > the proposal) > > > * Aspects (as per Steven Bethard's suggestion) > > > * Extension API (currently empty, and that hasn't hampered the > > discussions!!) > > > > > > I'd be OK with them going into an additional PEP, but to be honest, it > > > wouldn't bother me to see them left out of the PEP process > > > altogether[1]. (I don't feel that I have enough experience with > > > *using* GFs to comment meaningfully, so I'd be willing to defer to > > > Phillip's judgement here). > > > >That would suit me fine, since my inclination is to approve some form > >of the basics of the PEP (with reservations I will explain in another > >message) but to reject the second PEP. > > FYI, wrt to Paul's list, my own list for the 2nd PEP doesn't include > interfaces and adaptation; they'd be squarely in the first PEP. > > > > > [1] But I'd like to see them documented in the final implementation - > > > I'm not suggesting they be undocumented features. > > > >I'm suggesting they aren't features at all, except for the extension > >API. All the other stuff should be addable in a separate module using > >the extension API. > > I don't see what the benefit is of making people implement their own > versions of @before, @after, and @around, which then won't > interoperate properly with others' versions of the same thing. Even > if we leave in place the MethodList base class (which Before and > After are subclasses of), one of its limitations is that it can only > combine methods of the same type. There's no way for two different > user-implemented "befores" to merge at the same precedence level, > without some fairly fancy footwork on the implementer's part, or some > kind of convention being established as to how to tell whether a > method intends to be a before or after or whatever. (And this > same-precedence merging is critical feature of @before/@after, as > they are used mainly for "observer"-like hooks, where multiple > libraries may be observing the same thing.) > > So, one of the reasons for including those features (along with > Aspect) in the stdlib is the standardization part. Really, > standardization of a lot of this stuff is the main point to having a > PEP at all.
OK, let me repeat this request than: real use cases! Point me to code that uses or could be dramatically simplified by adding all this. Until, then, before/after and everything beyond it is solidly in YAGNI-land. > By the way, I'm not sure if I mentioned this before, but Ruby 2.0 is > supposed to include before/after/around qualifiers, except they're > called pre/post/wrap, and I'm not sure if the combination rules are > 100% the same as my before/after/around. And they're using Ruby's > open classes rather than standalone generic functions. But it's > another data point. > > Note that in current Ruby, you can simulate generic functions > (single-dispatch only) via open classes as long as you use > sufficiently-unique method names. The fact that Matz wants to add > these qualifiers seems to suggest that simple next-method chaining > (i.e. super) isn't as expressive as they'd like. Unfortunately, I > haven't been able to find an RCR for this feature, only references to > RubyConf slide presentations, so I don't know what their specific rationale > is. So if Matz jumped off a cliff, would you recommend I jump too? -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
