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. 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. _______________________________________________ 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
