[Python-3000] pep 3124 plans (original) (raw)
Phillip J. Eby pje at telecommunity.com
Fri Jul 13 19:41:47 CEST 2007
- Previous message: [Python-3000] test_mmap.py and OSError
- Next message: [Python-3000] pep 3124 plans
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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? :)
- Previous message: [Python-3000] test_mmap.py and OSError
- Next message: [Python-3000] pep 3124 plans
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]