OOP only in modules

[Adam Tauno Williams]

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.