[Python-3000] PEP Parade
Phillip J. Eby
pje at telecommunity.com
Wed May 2 03:40:41 CEST 2007
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.
More information about the Python-3000