[Python-3000] pep 3124 plans

[Phillip J. Eby]

At 11:58 AM 7/19/2007 +0100, Paul Moore wrote:
>1. The "Advanced" API - some people (including Guido?) do not see the
>need for the advanced features of the PEP such as method combinations.
>On the other hand, no-one has offered to write up of implement a
>reduced version.

Actually, two people have, if you count me.  The other one hasn't yet 
done any of the things we discussed that they could do, and it's 
still on my "to do eventually" list to take care of the rest, 
including an implementation.


>2. Functions being modifiable in-place. Technical issues with the
>implementation of the advanced API are complex to code without
>assuming that function objects can be modified (which Guido is
>unwilling to sanction in the general case). Furthermore, the PEP
>specifically states that @overload modifies existing functions
>in-place.
>
>3. All functions are generic - The PEP states that the @overload
>decorator will work on any function, which requires in-place
>modification. By requiring overloadable functions to be declared
>somehow (for example, using a decorator) this requirement could
>possibly be removed.

I've agreed to Guido's terms for this stuff, more than once, and am 
fine with having a restricted implementation that does things his 
way.  It just won't help me much with my goals for all this, unless 
we figure out a way for that to co-exist with what I want to do, and 
I haven't figured that out yet.

In the meantime, I've got other pressing projects for OSAF that are 
mostly keeping me from doing *anything* related to generic functions, 
even the stuff I *want* to do.  OSAF does use simplegeneric in parts 
of Chandler, btw, but my current work doesn't relate to those parts.

I don't have the cycles at the moment for a PEP rewrite *and* 
implementing another generic function engine besides the five I've 
already written (and the sixth one that's in progress now).  The 
original plan for PEP 3124 was to port peak.rules.core to 3.0 after 
some feature additions, but the stripped-down design calls for a 
different implementation -- especially since peak.rules.core modifies 
functions in place.

(A minor irony: one of the reasons I did it that way instead of 
creating custom objects and then optimizing them with C, was to make 
it possible for PyPy and Psyco to optimize the code.  In other words, 
it was intended to *enhance* portability to other Python platforms, 
not inhibit it!)