[Python-3000] pep 3124 plans

[Aurélien Campéas]

On Fri, Jul 13, 2007 at 01:41:47PM -0400, Phillip J. Eby wrote:
> 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.

At least on this list ?
Well, you could add me yo your count ... but who am I ? ;-)

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

Maybe it's just a silly data point, but the current Zope/Plone &
assorted products codebases are riddled with ad-hoc before, after
methods and hard-coded super-calls ... I don't know what these have
become in Zope 3 but at least this shows a need. Having standard ways
to specify these methods as gfs, would be a boon. OTOH having generic
functions without the standard method combination looks a bit like a
futile exercise; these are especially useful when you build hog
frameworks such as zope and whatever sits and tries to cooperate on
top of it.

Maybe thinking about method combination as 'dynamic decoration'
(paralelling the 'generic functions'/'dynamically overloadable
functions' terminology shift) would be a more friedly way to teach
python folks about the feature ? (Since it seems to me that python
wants to absorb foreign languages features under different names.)

I would have liked to have input on this from other people using
RuleDispatch features also (doesn't one of Django/Turbogears project
use them extensively ?). Just so the BDFL & lieutenants don't argue
too much in the direction of 'the community has no experience with
these things'. I think (wishfully ?) a sizeable, if not big, part of
the python *user* community is knwoledgeable about it. These people do
not necessarily express themselves there.

My two cents,
Aurélien.

> 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?  :)
> 
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/aurelien.campeas%40logilab.fr