At 05:34 AM 3/14/05 -0800, Michael Chermside wrote:
Nice... thanks. But I have to ask: is this really the right set of metadata to
be updating? Here are a few things that perhaps ought be copied by update_meta:


    f.__name__     (already included)
    f.__doc__      (already included)
    f.__dict__     (already included)
    f.__module__   (probably should include)
    f.func_code.co_filename     (to match f.__name__, but I'd leave it alone)

Leave __module__ alone, too, unless you want to play havoc with any inspection tools looking for the source code.



there's also the annoying fact that in IDLE (and in some other python-aware
IDEs) one can see the argument signature for a function as a "tool tip"
or other hint. Very handy that, but if a decorator is applied then all
you will see is "func(*args, **kwargs)" which is less than helpful. I'm
not sure whether this CAN be duplicated... I believe it is generated by
examining the following:

    f.func_code.co_argcount
    f.func_code.co_varnames
    f.func_code.co_flags & 0x4
    f.func_code.co_flags & 0x8

...and I suspect (experimentation seems to confirm this) that if you mangle
these then the code object won't work correctly. If anyone's got a
suggestion for fixing this, I'd love to hear it.

One solution is to have a __signature__ attribute that's purely documentary. That is, modifying it wouldn't change the function's actual behavior, so it could be copied with update_meta() but then modified by the decorator if need be. __signature__ would basically be a structure like the one returned by inspect.getargspec(). Also, 'instancemethod' would have a __signature__ equal to its im_func.__signature__ with the first argument dropped off, thus making it easy to introspect wrapper chains.


I discussed this approach with Guido in private e-mail a few months back during discussion about an article I was writing for DDJ about decorators. We also discussed something very similar to 'update_meta()', but never settled on a name. Originally he wanted me to PEP the whole thing, but he wanted it to include optional type declaration info, so you can probably see why I haven't done anything on that yet. :)

However, if we can define a __signature__ format that allows for type declaration, I imagine there'd be little problem with moving forward on it.

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to