On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > 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.
Thanks for indulging my insecurities. > 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. :) I'll take my cue from the users. > 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. That's one solution. Another solution would be to use GFs in Pydoc to make it overloadable; I'd say pydoc could use a bit of an overhault at this point. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
