Thanks everyone for the suggestions. I've implemented a simple solution using sys.settrace. It's quite nice because it doesn't require any instrumentation of the code (it works like a debugger that traps all function calls).
Here's the output I get right now when "profiling" Skip's example code (but without using decorators): fib2 (testee.py:8) 1 arguments n: <type 'float'> (1) <type 'int'> (23) main (testee.py:17) 0 arguments fib (testee.py:1) 1 arguments n: <type 'float'> (9) <type 'int'> (15) This means that fib2 has been called once with a float in the n parameter, and 23 times with an int, etc. There's more work to be done to make this a robust tool (which is why I was hoping there already existed a tool for this). It should handle varargs and keyword arguments properly, and probably needs to handle exceptions better. I'll see if I can run it on real code tomorrow and see if the results are useful. Martin On Mon, Oct 27, 2008 at 11:50 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > On 2008-10-26 13:54, Martin Vilcans wrote: >> Hi list, >> >> I'm wondering if there's a tool that can analyze a Python program >> while it runs, and generate a database with the types of arguments and >> return values for each function. In a way it is like a profiler, that >> instead of measuring how often functions are called and how long time >> it takes, it records the type information. So afterwards, when I'm >> reading the code, I can go to the database to see what data type >> parameter "foo" of function "bar" typically has. It would help a lot >> with deciphering old code. >> >> When I googled this, I learned that this is called "type feedback", >> and is used (?) to give type information to a compiler to help it >> generate fast code. My needs are much more humble. I just want a >> faster way to understand undocumented code with bad naming. > > You could try the trace module: > > http://www.python.org/doc/2.5.2/lib/module-trace.html > > but I'm not sure whether that includes parameter listings. > > Or write your own tracing function and then plug it into your > application using sys.settrace(): > > http://www.python.org/doc/2.5.2/lib/debugger-hooks.html#debugger-hooks > > The frame object will have the information you need: > > http://www.python.org/doc/2.5.2/ref/types.html#l2h-143 > > in f_locals. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Oct 27 2008) >>>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > > :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: > > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > -- [EMAIL PROTECTED] http://www.librador.com -- http://mail.python.org/mailman/listinfo/python-list
