On Sun, Jan 30, 2011 at 3:16 PM, Roberto Cavada <roboo...@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 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. >> I could just ditch the class and have all the class >> methods be top-level module function definitions, and then I could >> rename "main.py" into "appname.py", and in my runner script, change >> this code: >> >> from appname.main import AppName >> AppName().main() >> >> into this: >> >> from appname import appname >> appname.main() > > Frankly I cannot see a substantial difference in terms of quality. > (Can you measure the quality from the number of keystrokes?) 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. > 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. I 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. > 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? Either way there is a rigid API that I can be held to for compatibility, the only difference is that if I get rid of the class, then the module _itself_ can be treated as if it is an instance of what was previously the class. In fact, doing it the way I suggest makes it easier to enforce that there be only one instance, because modules can only be imported once (Python enforces this; secondary import statements are effectively no-ops). > decompose the application into hierarchies of functional modules, you > will very quickly end up floundering into a spaghetti nightmare if you > don't organize your code base accordingly. I'm well aware of the benefits of having short, well-defined functions. My app is quite well organized. The question was simply "is there some benefit I don't see to having these particular functions be part of a class, rather than just having them as module top-levels and pretending that the module itself behaves like an instance of the class?" >> Another reason why I care about this issue is that method invocations >> are slower when there's a period in the name, so eg calling >> "self.foobar()" is by definition slower than simply calling >> "foobar()", so there's a minor speed boost to be had by ditching the >> class and replacing it with all module-global functions. > > In python, generally, these optimizations are not very meaningful. Your > may be trying to reduce complexity of your algorithms, but one further > level of indirection and similar details make no actual difference. > > Much more important is how your code looks like (do you really exploit > the language, or do you write your code like e.g. in java?), and how > your code is organized. My personal way for evaluating python code I > write and read, is wonder if I can understand what a function does > without worrying about the details of the implementation. If not > convinced, there is certainly a better approach to make it better > (shorter, more elegant, more readable). 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. >> One thing I changed recently that got me thinking about this is that I >> changed GtkBuilder from being an instance variable to a top-level >> module variable. > > Sometimes I use aliases like you, especially in loops where it makes > sense, but only if the alias is kept local and close to the place where > it is used. However, introducing aliases makes the code harder to > understand, and if the alias is global to the module (like in your > example) the code is less portable/usable prone to errors. 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. Feel free to peek at my code if you like: https://github.com/robru/GottenGeography/blob/jhbuild/gg/app.py -- http://exolucere.ca _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
