[Python-3000] PEP Parade (original) (raw)

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 mailing list