[Tutor] Clash of the Titans and Mundane Matters

[Michael Powe]

Clash of the Titans

>From "Dive into Python":

__init__ is called immediately after an instance of the class is
created. It would be tempting but incorrect to call this the
constructor of the class. It's tempting, because it looks like a
constructor (by convention, __init__ is the first method defined for
the class), acts like one (it's the first piece of code executed in a
newly created instance of the class), and even sounds like one ("init"
certainly suggests a constructor-ish nature). Incorrect, because the
object has already been constructed by the time __init__ is called,
and you already have a valid reference to the new instance of the
class. But __init__ is the closest thing you're going to get to a
constructor in Python, and it fills much the same role.

>From Alan's book "Learning to Program":

One of the methods of this class is called __init__ and it is a
special method called a constructor. The reason for the name is that
it is called when a new object instance is created or constructed. Any
variables assigned (and hence created in Python) inside this method
will be unique to the new instance. There are a number of special
methods like this in Python, nearly all distinguished by the __xxx__
naming format.

----------------
Mundane Matters

I'm having a hard time with classes in python, but it's coming
slowly.  One thing that I think is generally difficult is to parse a
task into "objects."  Here's an example:  in Java, I wrote an
application to track my travelling expenses (I'm a consultant; this
tracking of expenses is the itch I am constantly scratching.  ;-)
I've also written this application in a perl/CGI web application as
well.)  It's easy to see the outline of this task:  create an abstract
class for expense and then extend it for the particular types of
expenses -- travel, food, transportation, lodging and so forth.  In
python, I guess I'd create a class and then "subclass" it.  But
... what are reading/writing to files and printing?  Of course, I
create a "file object" in order to accomplish these tasks -- but how
is this object fit into the application design?  Do I just create
methods within the expense class to accomplish these parts of the
task?  When I tried this on, it seemed hacky.  The other option seemed
to be creating an I/O class and passing the expense objects to it.
But, should that class be an interface or an object?  The one thing
you don't see in "how to program" java books is an implementation of
I/O in the context of an application.

A similar problem occurs with my HTML-parsing routine that I brought
to the list recently.  Use of HTMLParser was suggested.  I've looked
into this and usage means subclassing HTMLParser in order to implement
the methods in the way that will accomplish my task.  Conceptually,
I'm having a hard time with the "object" here.  (The fairly poor
documentation for HTMLParser doesn't help.)  Apparently, I'm creating
a "parser" object and feeding it data.  At least, that's the closest I
can get to understanding this process.  How I'm actually feeding data
to the "parser" object and retrieving the results are matters open to
discussion.  I'll be working on that when I get another chance.

Finally, in terms of "understanding python," the question I keep
coming up against is:  why do we have both functions and methods?
What is the rationale for making join() a string method and a os.path
function?

Thanks for your time.  It's late.  ;-)  Sometimes, I just have to get
these things off my chest.

mp