[Python-3000] pep 3124 plans

[Paul Moore]

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.