Beginning to learn python...help needed!

Will Ware wware at world.std.com
Mon Feb 5 18:41:54 EST 2001


Martyn Quick (mrq at for.mat.bham.ac.uk) wrote:
> I'm having trouble understanding the "Object Oriented" part of
> the programming.  Can anyone give some advice when is the right time to
> use a class, as opposed to just using the def command?

Here is what I do. I usually start out writing some functions and some
global data structures. Then I notice that data structure A is only used
by functions f and g, and data structure B is only used by functions d
and e. It kinda makes sense to think of (A, f, g) as a sort of package
deal: a computational beast that knows how to perform actions f and g,
and has internal knowledge A, but for the most part, nobody interacting
with this beast needs to deal much directly with A. This beast is then
an object:

class Beast_Afg:
  def __init__(self, ...):
    self.A = <initial value for A>
  def f(self, ...):
    do stuff with self.A
    return something, maybe
  def g(self, ...):
    do stuff with self.A
    return something, maybe

mybeast = Beast_Afg(...)    # and here is how you might use it
mybeast.f(...)
mybeast.g(...)

The next question is, why is this advantageous over the global functions
and global data structure? A couple of reasons. You can hide the definitions
for Beast away in some file that you don't look at very often, to avoid
confusing yourself with too many details. Because each copy of Beast has
its own copy of A, you can have several beasts existing simultaneously
without messing up each others' data. And once you get used to the idea
of structuring stuff as objects, you'll find it quite pleasant and easy
on the poor frazzled neurons.

The downside to objects is that, in order to have useful ones, you need
to invest some time and energy into designing them well. That is, choosing
good choices for A, f, and g, and giving them clear descriptive names.
People sometimes think that object-oriented programming is magical and they
won't have to do any more thinking or working. It's a different (and often
better) way to organize your work but the work still needs to be done. In
particular, people often claim that OOP leads directly to easily-reused
code, much more so than conventional (e.g. C) code. It can, if you invest
the effort to design objects well, and you're prepared to take feedback
from whoever uses those objects (since you probably won't get it exactly
right the first time). There are also tricks for making non-OOP C code
reusable, if you're willing to work equally hard at it.

> I'm also getting nowhere with Tkinter.

I've heard good things about the John Grayson book mentioned in another
response, and intend to pick up a copy one of these days. I find that a
great thing to look at is the Demo/tkinter directory in the Unix source
code for Python. There are lots of examples, and you can try them to see
what they do. Pick one that is doing approximately what you want, and
start tinkering with it.

-- 
import string,time,os;print string.join((lambda x:x[:10]+x[8:])(map(
lambda x:string.center("*"*(lambda x:((x<24) ### Seasons Greetings, Will Ware
*(x-3))+3)(x),24),range(1,28, 2))),"\n") ################ wware at world.std.com



More information about the Python-list mailing list