[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.

[Guido van Rossum]

On 5/14/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 08:29 AM 5/14/2007 -0700, Guido van Rossum wrote:
> >On 5/14/07, Paul Moore <p.f.moore at gmail.com> 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/)