[pygtk] python modules/classes best practices?

[A.T.Hofkamp]

Robert Park wrote:
> On Sun, Jan 30, 2011 at 3:16 PM, Roberto Cavada <roboogle at gmail.com> wrote:
>> On Sat, 2011-01-29 at 23:22 -0700, Robert Park wrote:
>> [...]
>>> But I just can't shake this feeling that having a class to represent
>>> just the GUI when it's already inside of a module is somehow
>>> redundant. There will only ever be one instance of that class. What
>>> good is that?
>> The fact that classes can be instantiated multiple times is not the
>> (only) reason for having classes. Inheritance and polymorphism give the
>> real sense to OOP - IMO - and having information hidden into hierarchies
>> and relations make the design easy to understand, extend, maintain, etc.
> 
> Ok, but I'm asking if the module itself provides the same "heirarchies
> and relations" that I'm getting from the class. That is, when my

No, you don't have inheritance with modules.

> entire project was in one file, it made sense to have the class for
> it's encapsulation, but now that the other classes are in other files,
> the module _itself_ is providing the same encapsulation that the class
> was giving me, and is thus redundant.

Sort of, indeed.

That holds, until you add a second window, or you create custom widgets that you use in your 
application GUI.
(At least, that is where I'd expect those things.)

> My point with that example was not that the second version was better,
> but that they were so similar that it proves that the module itself is
> "good enough" and that I don't actually benefit from having this
> particular class inside a module.

One concept you may want to keep is that 'import xyz' does nothing except importing.
If you perform assignments at toplevel, importing has side effects.
For normal execution this is not a problem, for debugging it may be useful to have to explicitly 
call setup, like you have in __init__(self).

> Ok, but how does having module top-level functions instead of class
> instance methods (for a class that can only be instantiated once) make
> any difference? Either way there is a rigid API that I can be held to

For your case, it matters very little. The question is mostly when do you move the code one level 
deeper, now, or when you want to extend the program.
The disadvantage of the latter is that you first need to do refactoring before you can extend. Since 
that may happen after 2 years, it means you then have to understand what you did now.

Another consideration is other users, and/or other programs.
Other users will expect things to be one level deeper, so for their readability it is advisable to 
code it that way.
In the same way, if you make more of these programs, chances are you are also going to make programs 
where the code is one level deeper. That means that you will have two coding styles for the 
top-level function instead of one, which is more difficult to manage correctly.


> Well, one way that i'm attempting to make everything more readable is
> by getting rid of the term "self" that is littered throughout my
> program.

Every Python programmer understands what self means. He/she knows instantly what you are doing.
Don't confuse 'short code' with 'readable code'. While related, they are not the same thing.


Just my 2 cents,
Albert