[Python-3000] PEP Parade

[Phillip J. Eby]

At 05:52 PM 5/1/2007 -0700, Guido van Rossum wrote:
>I rather like the idea that it warns readers who are new to GFs and more 
>familiar with how functions behave in Python 2.

Until somebody adds an overload, it *does* behave the same; that was sort 
of the point.  :)

>Also noting that __code__ is an implementation detail --
>it doesn't exist for other callables such as built-in functions.

Fair enough, although the PEP doesn't propose to allow extending built-in 
functions, only Python ones.

>I would be rather fearful of someone else stomping on a function I defined 
>(and which I may be calling myself!) without my knowing it.

All they can do is add special cases or wrappers to it; which is not quite 
the same thing.  It's actually *safer* than monkeypatching, as you don't 
have to go out of your way to save the original version of the function, 
your method is only called when its condition applies, etc.  For simple 
callbacks using before/after methods they needn't even remember to *call* 
the old function.

However, since your objections are more in the nature of general unease 
than arguments against, it probably doesn't make sense for me to continue 
quibbling with them point by point, and instead focus on how to move forward.

If you would like to require that the stdlib module use some sort of 
decorator (@overloadable, perhaps?) to explicitly mark a function as 
generic, that's probably fine, because the way it will work internally is 
that all the overloads still have to pass through a generic 
function...  which I can then easily add an overload to in a separate 
library, which will then allow direct modification of existing functions, 
without needing a decorator.  That way, we're both happy, and maybe by 3.1 
you'll be comfortable with dropping the extra decorator.  :)

One possible issue, however, with this approach, is pydoc.  In all three of 
my existing generic function libraries, I use function objects rather than 
custom objects, for the simple reason that pydoc won't document the 
signatures of anything else.  On the other hand, I suppose there's no 
reason that the "make this overloadable" decorator couldn't just create 
another function object via compile or exec, whose implementation is fixed 
at creation time to do whatever lookup is required.