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 <mal@egenix.com wrote:
--
martin@librador .com
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 <mal@egenix.com wrote:
On 2008-10-26 13:54, Martin Vilcans wrote:
>
You could try the trace module:
>
>
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():
>
>
The frame object will have the information you need:
>
>
in f_locals.
>
--
Marc-Andre Lemburg
eGenix.com
>
Professional Python Services directly from the Source (#1, Oct 27 2008)
_______________ _______________ _______________ _______________ ____________
>
:::: Try mxODBC.Zope.DA for Windows,Linux,S olaris,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
>
>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.
>>
>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:
>
>
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():
>
>
The frame object will have the information you need:
>
>
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.Adapte r ... http://zope.egenix.com/
>>>mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
>>>mxODBC.Zope. Database.Adapte r ... http://zope.egenix.com/
>>>mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
>
:::: Try mxODBC.Zope.DA for Windows,Linux,S olaris,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@librador .com
