On Tue, 2011-04-12 at 08:33 -0700, newpyth wrote:
> """ call tree w/o classes and objects:
> E() #~15 called from #~35
> +-- F() #~18 16
> | +-- raw_input('Addressed to ') # called from 19
> +-- G() #~21 18
>
> G() #~21 36
> """
> </code>
> Beeing the script so small, the above call tree can be
> build up by hand,
IMO, in any real-world application your call-graph is miles long. This
is really not much more than a stack trace.
> It not an easy task... therefore I called help.
> in my experience, I am convinced that call trees (together with xref)
> are the main tools to understand not trivial python programs.
> Instead of using debuggers,
Even better, since the real world usually involves non-trivial programs,
is to learn to use debuggers and the provided tools. I've not had any
issues read the strack-trace generated by an exception in an OO Python
application [as I maintain a >100,000 line and growing component
oriented Python applications
<https://www.ohloh.net/p/coils/analyses/latest>]
> with these tools (and with the
> judicious use of trace) you can solve any bug and besides that
> acquire a better understanding of the program.
> Another advantage of moving OO stuff to modules is the "sharp
> increase in re-usability of code...
Only if your code remains as trivial as your examples.
> In my understanding modules are the python's implementation
> of libraries very much used by other languages.
Making these kind of analogies is not helpful and will only confuse. C
uses libraries, .NET uses assemblies, Python uses modules... and how
these function and perform differs in important ways.
--
http://mail.python.org/mailman/listinfo/python-list
