[Python-3000] PEP Parade (original) (raw)
Guido van Rossum guido at python.org
Wed May 2 04:37:55 CEST 2007
- Previous message: [Python-3000] PEP Parade
- Next message: [Python-3000] PEP Parade
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 5/1/07, Phillip J. Eby <pje at telecommunity.com> 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/)
- Previous message: [Python-3000] PEP Parade
- Next message: [Python-3000] PEP Parade
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]