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

Phillip J. Eby pje at telecommunity.com
Thu Jul 19 18:16:30 CEST 2007

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!)

More information about the Python-3000 mailing list