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

Paul Moore p.f.moore at gmail.com
Thu Jul 19 12:58:54 CEST 2007

On 19/07/07, Aurélien Campéas <aurelien.campeas at logilab.fr> wrote:

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 ? ;-)

I don't think the issue is quite as black and white as Phillip is stating it. I personally have no immediate need for his more advanced API, but I'd support its inclusion if that meant increasing the chance of any GF API going into the core.

There really ought to be an "Open Issues" section of the PEP, capturing the key areas where we don't have agreement. The lack of such a section is what makes it almost impossible to follow the discussions, insofar as how they make progress towards accepting the PEP.

As a contribution to the discussion, may I offer the following as the key items I believe are open:

  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.

  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.

My apologies if I've misrepresented anyone's views. Please correct me if I have! I hope this is of some use.

Paul.

More information about the Python-3000 mailing list