Type feedback tool?

Martin Vilcans martin at librador.com
Mon Oct 27 23:21:25 CET 2008

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.


On Mon, Oct 27, 2008 at 11:50 AM, M.-A. Lemburg <mal at egenix.com> 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

martin at librador.com

More information about the Python-list mailing list