[pygtk] python modules/classes best practices?

[Roberto Cavada]

On 01/30/2011 11:53 PM, Robert Park wrote:

  
> [...] 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.


In this perspective, you are using classes as mere namespaces of 
your functions and variables. As I said, if you do not exploit 
hierarchies and relations (and you don't as you have no inheritance 
and no polymorphism) there is very little difference between module 
and class levels (IMO there are some disadvantages with modules, see 
below).

> 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.


If you don't see advantages with classes, let's stay with benefits 
of having only modules. Do you see any that are not syntactic like 
number of dots between IDs and 'self' appearing as first formal param?

>> Indeed if your application code fits into a thousand of LOC, you can
>> choose whatever style you like, either having everything pushed into one
>> module or split into classes/packages/modules, no really matters.
>
> Ok, but I am not arguing against all classes, just the class that
> represents the graphical interface that the user interacts with.


Then I guess your GUI is necessarily very small. I cannot imagine a 
large GUI all fitted into a module, and even within one single 
class. How do you separate the GUI logics and the presentation 
layers? Can you split the GUI into (interconnected, still decoupled) 
pieces? ( someone calls them components.) If you have components, 
you can reuse/factorize code in different parts of a single 
application, or you can rearrange the GUI for another application.

> have a handful of classes that represent various kinds of data that my
> application uses, and that makes great sense because each class can be
> instantiated multiple times and each instance represents something
> meaningful.


Typically the top-level logics, controller and presentation of the 
GUI is instantiated only once, but this does not mean that it is not 
meaningful. Again, classes are not supposed to be instantiated 
multiple times.

>> However, if your application is intended to grow up, if you need
>> contracts (interfaces) to agree with other programmers, if you need to
>
> 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?


In principle no, in practice it largely helps. I think it is trivial 
to say that the introduction of OOP did not change the software, as 
you can do whatever with a procedural-paradigm, as well as you can 
do OOP with a non-OOP language. OOPs is only for reducing 
(hopefully) costs of software.

> Can you explain how module-globals make code less portable? Is there a
> platform on which Python doesn't support module globals? I'm genuinely
> curious.


Mmm, 'portability' was a bad term I chose, as it can create 
misunderstandings I am sorry about that. I probably had to talk 
about 'reuse'. Extending my objections, what if you wanted to have:
- threads involved
- unittests of some parts
- code generated by metaclasses at compile time
- refactoring needs, e.g. you want to move your code (or part of it) 
in a different possibly larger place.

If you have poor locality of your code, you'll get into troubles. 
Using module-level variables does not help with locality.

My two cents,
r.