Inferring initial locals()

George Sakkis george.sakkis at gmail.com
Mon Jun 25 01:01:55 EDT 2007


On Jun 24, 10:52 pm, Scott David Daniels <scott.dani... at acm.org>
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




More information about the Python-list mailing list