[Python-3000] pep 3124 plans

[Phillip J. Eby]

At 07:39 AM 7/13/2007 +0200, Michele Simionato wrote:
>But I want to ask your opinion first, in order to understand if you 
>are willing to scale down your proposal or not. At EuroPython Guido 
>said that in private mail you made some strong argument explaining 
>why the PEP could not be simplified, but he did not say more than that

It's not an argument that the PEP can't be simplified; only that a 
simpler PEP won't accomplish my original goal for the PEP (of having 
a generic API for generic functions) vs. simply having a generic 
function implementation in the stdlib.  The first goal requires the 
second, but the second doesn't need the first, and as far as I'm 
aware, I'm the only person who really wants the first.

A simpler PEP could exist to implement the second goal only, 
implementing dynamic overloading in Python 3.0 with all of the 
non-controversial features of 3124, and using Guido's preferred API.

The holdup is that I don't have time to work on the *implementation* 
of both my version *and* this simplified version; there is little 
overlap between the two because mine is highly 
self-referential/self-bootstrapping, absolutely dependent on being 
able to modify functions in-place (a feature Guido seems near -1 on), 
and virtually impossible to scale down.

So, it is much lower on my priorities at the moment to implement the 
simplified version, because I will neither gain code reuse *nor* the 
API standardization I'd hoped for.

At the moment, my plan is to finish implementing a PEP 3124-like, 
fully extensible implementation for Python 2.x (see PEAK-Rules), then 
look at splitting 3124 into a simplified version and a separate 
extension API PEP aimed at Python 3.1 or later.  At that point, I 
will know for sure what extension API features are necessary to 
implement the more advanced features I want in PEAK-Rules.

I expect to be able to start work on this (i.e., revisiting the 
proposal) in about a month.  With luck, I will be able to carve out 
enough time to create the simpler implementation and update the PEP 
in a reasonable amount of time.

However, there is nothing stopping anyone else who wishes it from 
either making the simpler implementation or drafting the scaled-down 
PEP.  The simpler version Guido wants isn't really that different 
from his existing generic function prototype, especially if you drop 
all forms of method combination (including :next_method).  It will 
also need positional dispatching, but that's another feature that 
could perhaps wait for 3.1 as well.

In short, if you want a PEP 3124 implementation started on sooner 
than about a month from now, you need to find a volunteer or do it yourself.


>The point is that for 95% of my use cases, simplegeneric would be 
>enough, and it is alreay available *now*. So, if Guido was willing 
>to accept something like simplegeneric for Python 3.0, I would not 
>mind waiting for multiple dispatch in 3.1.

You'll have to ask him about that.  For what it's worth, the pkgutil 
module already contains an even simpler generic function 
implementation than simplegeneric, and is already in the stdlib 
albeit undocumented.


>The reason why I am not using simplegeneric or RuleDispatch already, 
>is that I do not want to commit in production to a technology 
>without the official approval of the BDFL, and I prefer to wait now 
>than having to change my code later.

I guess this means you never use any packages from the Cheeseshop?  :)