[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.

Phillip J. Eby pje at telecommunity.com
Thu May 10 17:59:41 CEST 2007

At 08:43 PM 5/9/2007 -0600, Steven Bethard wrote:
>>Meanwhile, leaving in the ability to have method combination later,
>>but removing the actual implementation of the @before/around/after
>>decorators in place would delete a total of less than 40 non-blank
>>lines of code.
>Sure, but it would also delete huge chunks of explanation about
>something which really isn't the core of the PEP. Python got
>decorators without the 6 lines of functools.update_wrapper -- I see
>this as being roughly the same. In particular,
>functools.update_wrapper was never mentioned in PEP 318.

I see this as being more analagous to contextlib.contextmanager and 
PEP 343, myself.  :)

>I'm just hoping you can find a way to cut the PEP
>down enough so that folks have a chance of wrapping their head around

Well, it's a bit like new-style types, in that there are a bunch of 
pieces that go together, i.e., descriptors, metaclasses, slots, and 
mro.  I could certainly split the PEP into separate documents, but it 
might give the impression that the parts are more separable than they are.

>  ;-)  I really do think something along these lines
>(overloading/generic functions) is right for Python.  I just think the
>current PEP is too overwhelming for people to see that.

Yeah, and the dilemma is that if I go back and add in all the 
examples and clarifications that have come up in these threads, it's 
going to be even bigger.  Ditto for when I actually document the 
extension API part.  The PEP is already 50% larger (in text line 
count) than the implementation of most of its features!  (And the 
implementation already includes a bunch of the extension API.)

I'm certainly open to suggestions as to how best to proceed; I just 
don't see how, for example, to explain the PEP's interfaces without 
reference to generic functions.  So, even if it was split into 
different documents, you'd still have to read them in much the same 
order as in the one large document.

By the way, I have gotten off-list notes of encouragement from a 
number of people who've said they hope the PEP makes it, so evidently 
it's not overwhelming to everyone.  Unfortunately, it seems to be 
suffering a bit from Usenet Nod Syndrome among the people who are in 
favor of it.

More information about the Python-3000 mailing list