Comments on: Generating call graphs for understanding and refactoring python code http://blog.prashanthellina.com/2007/11/14/generating-call-graphs-for-understanding-and-refactoring-python-code/ ( to ) ? be : ! be; Fri, 25 Jul 2008 15:00:14 +0000 http://wordpress.org/?v=2.5 By: Computer Forum http://blog.prashanthellina.com/2007/11/14/generating-call-graphs-for-understanding-and-refactoring-python-code/#comment-4863 Computer Forum Tue, 22 Jul 2008 11:21:11 +0000 http://blog.prashanthellina.com/2007/11/14/generating-call-graphs-for-understanding-and-refactoring-python-code/#comment-4863 Amazing article! Detailed and very interested. I am going to recommend this blog to my friends. Amazing article! Detailed and very interested. I am going to recommend this blog to my friends.

]]> By: prashanthellina http://blog.prashanthellina.com/2007/11/14/generating-call-graphs-for-understanding-and-refactoring-python-code/#comment-4338 prashanthellina Sun, 15 Jun 2008 05:10:28 +0000 http://blog.prashanthellina.com/2007/11/14/generating-call-graphs-for-understanding-and-refactoring-python-code/#comment-4338 Rick, the code is available already for download. You can find the link in the blog post. Rick, the code is available already for download. You can find the link in the blog post.

]]> By: Rick http://blog.prashanthellina.com/2007/11/14/generating-call-graphs-for-understanding-and-refactoring-python-code/#comment-4335 Rick Sun, 15 Jun 2008 01:42:58 +0000 http://blog.prashanthellina.com/2007/11/14/generating-call-graphs-for-understanding-and-refactoring-python-code/#comment-4335 Thanks for this - great idea. I was wondering if you would be willing to send me the script (and any dependencies) you use on this site to generate the graph. I have an entirely different kind of data that I would like to graph in a similar way. Thanks again, Rick Thanks for this - great idea.

I was wondering if you would be willing to send me the script (and any dependencies) you use on this site to generate the graph.
I have an entirely different kind of data that I would like to graph in a similar way.

Thanks again,
Rick

]]> By: prashanthellina http://blog.prashanthellina.com/2007/11/14/generating-call-graphs-for-understanding-and-refactoring-python-code/#comment-630 prashanthellina Fri, 23 Nov 2007 12:55:54 +0000 http://blog.prashanthellina.com/2007/11/14/generating-call-graphs-for-understanding-and-refactoring-python-code/#comment-630 I find it hard to imagine that "entirely different" functions will be calling each other. an example? I believe that functions that call each other will be doing some common task. Also, increase in speed is not a necessary goal of refactoring. In fact in python when you split a function into smaller functions, you incur a performace hit (albeit very small). The goal is to make the code more maintainable. I find it hard to imagine that “entirely different” functions will be calling each other. an example? I believe that functions that call each other will be doing some common task. Also, increase in speed is not a necessary goal of refactoring. In fact in python when you split a function into smaller functions, you incur a performace hit (albeit very small). The goal is to make the code more maintainable.

]]> By: vikraman http://blog.prashanthellina.com/2007/11/14/generating-call-graphs-for-understanding-and-refactoring-python-code/#comment-627 vikraman Fri, 23 Nov 2007 10:42:49 +0000 http://blog.prashanthellina.com/2007/11/14/generating-call-graphs-for-understanding-and-refactoring-python-code/#comment-627 This is a good way to split a big python script into smaller ones and including them in one "master script". But i'm not sure whether such a division will be correct "functionally" because you might have to group functions that perform entirely different things in one file. plus, There may not be an increase in speed in doing such a thing. However from the point of view of a programmer its pretty neat. This is a good way to split a big python script into smaller ones and including them in one “master script”. But i’m not sure whether such a division will be correct “functionally” because you might have to group functions that perform entirely different things in one file.
plus, There may not be an increase in speed in doing such a thing. However from the point of view of a programmer its pretty neat.

]]> By: prashanthellina http://blog.prashanthellina.com/2007/11/14/generating-call-graphs-for-understanding-and-refactoring-python-code/#comment-445 prashanthellina Wed, 14 Nov 2007 07:08:46 +0000 http://blog.prashanthellina.com/2007/11/14/generating-call-graphs-for-understanding-and-refactoring-python-code/#comment-445 Although I have not tried yet, extending the script to handle modules and classes should be straight-forward. Like you said, evals, execs and functions being passed around are difficult to handle. Do keep me posted if you get somewhere along these lines. Thanks! Although I have not tried yet, extending the script to handle modules and classes should be straight-forward. Like you said, evals, execs and functions being passed around are difficult to handle. Do keep me posted if you get somewhere along these lines. Thanks!

]]> By: Hugo http://blog.prashanthellina.com/2007/11/14/generating-call-graphs-for-understanding-and-refactoring-python-code/#comment-444 Hugo Wed, 14 Nov 2007 06:56:24 +0000 http://blog.prashanthellina.com/2007/11/14/generating-call-graphs-for-understanding-and-refactoring-python-code/#comment-444 Wow! That's sweet... I'll give it a whirl when I have a big graph to generate. pycallgraph's speed (slow) made me think it is most useful to use it selectively on particular unit tests - but then I'd have to have good unit tests, which I don't always have. How tough is it to extend this kind of thing to multiple modules? And what will it not work on, eval statements, obviously. How about use of "getattr" and similar? Basically any time a function is passed as a string, the call will be missed. Right? Wow! That’s sweet… I’ll give it a whirl when I have a big graph to generate. pycallgraph’s speed (slow) made me think it is most useful to use it selectively on particular unit tests - but then I’d have to have good unit tests, which I don’t always have.

How tough is it to extend this kind of thing to multiple modules? And what will it not work on, eval statements, obviously. How about use of “getattr” and similar? Basically any time a function is passed as a string, the call will be missed. Right?

]]>