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

Aurélien Campéas aurelien.campeas at logilab.fr
Thu Jul 19 10:42:15 CEST 2007

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 :nextmethod). 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

More information about the Python-3000 mailing list