OO on python real life tutorial?

[Diez B. Roggisch]

filippo schrieb:
> thanks Fredrik and Claudio,
> 
> probably structured coding paradigm is what I need. Claudio, could you
> explain better your sentence below?
> 
> Claudio Grondi ha scritto:
>> Python/Tk for it in order to avoid programming in wxPython if not really
>> necessary (wxPython has its strengths with growing project sizes, but
>> yours is still far below the threshold).
> 
> I want to switch to wxpython because I don't like Tk too much. It is
> difficult sometimes to have full control of the widgets (i.e. focus
> sequence). Why do you think wxwidget is not suitable for low-medium
> size projects? Could you give me some practical examples of this?

You shouldn't take that advice too serious. He does not know much about 
your project, yet still he advices you to discard OO - that is just 
preposterous. His advice regarding the toolkit - well, you seem to have 
experienced difficulties in tk, so ditch it if you like.

While OO isn't the silver bullet, it certainly has its merits, and to be 
honest: I can't believe that there exist many 10k lines of code programs 
with database access and the like that don't gain from using OO principles.

Of course you can create data structures that fit your need - dicts and 
lists. But the least OO gives you is to name these, for better 
understanding. E.g.

class Hotel(object):
     def __init__(self, name):
         self.name = name

     def __str__(self):
         return "<Hotel: %s>" % self.name

which won't work better from a functional point of view than

{hotel_name = "Funny Horse House"}

But the type Hotel then introduces better readability, especially for 
others.

The very moment you have code that looks like this:


if  hotel["type"] == 'whatever':
     do_something_with_whatever(hotel)
else:
     do_something_with_rest(hotel)

overloading will come to use, and OO plays out its strength:

class Hotel(object):
     def __init__(self, name):
         self.name = name

     def __str__(self):
         return "<Hotel: %s>" % self.name

     def do_something(self):
         pass


class WhateverHotel(Hotel):
     def do_something(self):
         # we're doing something completely different here
         pass


Then you just do

hotel.do_something()

So the code hasn't to know anything about the possible differences in 
hotel types.

I've been doing an online hotel reservation system, btw, and I assure 
you: OO was very helpful, even in its crappy PHP incarnation.

Diez