On Jun 24, 10:52 pm, Scott David Daniels <[EMAIL PROTECTED]> wrote: > So, what should your code do about this: > > def someFunction(a, b, c=43, d=14, f=12): > print locals() > > import functools > > a_funct = functools.partial(someFunction, d=13, c=5) > b_funct = functools.partial(a_funct, 14, d=12) > localsProber(b_funct)
Didn't get too far :) Traceback (most recent call last): File "locprobe.py", line 54, in <module> localsProber(b_funct) File "locprobe.py", line 9, in localsProber args, varargs, varkw, defaults = inspect.getargspec(callable) File "C:\Python25\lib\inspect.py", line 728, in getargspec raise TypeError('arg is not a Python function') TypeError: arg is not a Python function > My point is simply: > Introspection code is often written with a fixed idea of what other > programmers write. The others don't use introspection, the others > don't use higher order functions to build functions, .... Fair enough, especially since not even the standard inspect module handles functools.partial objects. Perhaps things will improve after 2.6 with PEP 362 (Function Signature Object) in place. What you claim about introspection code though I think holds for code in general. There are quite often edge cases which the programmer doesn't anticipate or care to handle. A tool that covers X% of real- world use cases for some large X and documents the known limitations for the rest 100-X is fine with me (e.g. the current lambda). George -- http://mail.python.org/mailman/listinfo/python-list