Summer reading list

[Harry George]

mis6 at pitt.edu (Michele Simionato) writes:

> "Joe Cheng" <jmcheng at alum.mit.edu> wrote in message news:<mailman.1060713261.4958.python-list at python.org>...
> > To me it sounds disturbingly like "Procedures are more flexible than
> > classes because you can compose classes out of procedures."
> 
> I would subscribe that. Not that I dislike inheritance, but  I don't kill
> a mosquito with a bazooka.
> 
> Let me give a real life example, happened to me recently. 
> 
> I had a class manipulating text, with a "dedent" method. It turns out
> that the "textwrap" module included in the Python 2.3 distribution
> contains a "dedent" function doing exactly the same.
> Then I had the satisfaction of killing my own implementation,
> and to add to my class the textwrap.dedent function just with one
> line of code, "dedent=staticmethod(textwrapper.dedent)". I am
> very happy with that because:
> 
> 1) I shortened my class;
> 2) I reused pre-existing code;
> 3) I trust the developers of the standard library more than myself;
> 4) If the standard library contains bugs, they are much more easily
>    discovered than my own bugs;
> 5) the burden to fix them is up the Python developers, not me ;)
> 
> The fact that "dedent" was a function and not a method in a class
> made my life easier. I had not to worry about inheriting from another
> class with potential name clashes with my own, and "dedent" was the
> only function I needed.
> 
> Fortunately, quite a lot of modules in the standard library are
> written without a class interface and I would date say I have never 
> seen an example of usage of a class when the class is not needed.
> 
> In other words: most of the time a lightweight approach is more than
> appropriate, why should I be forced to take a heavy weight approach?
> The fact of having "free" functions (i.e. not bounded to classes) is
> to me a big strenght of Python and it helps reuse of code quite a lot.
> 
> To reuse classes is good, but typically only works when you know
> about the class you want to inherit *before* you start coding your
> own class; on the other hand, it is quite easy to add functions
> or methods to your class even *after* you wrote it.
> 
> Moreover, this is nothing wrong about using many short modules collecting 
> utilities functions, you will never clutter your namespace, if you use
> a minimum of care (even globals are globals only in their module,
> I love that! ;) 
> 
> I tend to code in terms of small functions, then I compose them in
> small classes, then I compose the classes in modules. When I am
> done, I play with metaclasses if I need to modify what I wrote
> with a minimum of effort.
> 
> There are quite few languages that can give you such a flexibility,
> and no one simpler to use than Python.
> 
> Just my own view,

On the other hand, I have a "TabbedWriter" module which uses a class
which has a dedent (actually "undent") method.  This class has
internal memory to track current indentation level (e.g., for indented
XML files).  Dedenting need to know this information.

If I had used a module with dedent as a function and saved level as a
global in the module, I would be limited to only 1 tabbed writer per
application.  I often need several going at once.

> 
> 
>                    Michele

-- 
harry.g.george at boeing.com
6-6M31 Knowledge Management
Phone: (425) 342-5601