Hi, 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. > 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?) 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. However, if your application is intended to grow up, if you need contracts (interfaces) to agree with other programmers, if you need to 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. python-gtkmvc <http://sourceforge.net/apps/trac/pygtkmvc/wiki> may be overkilling for toys and small applications, but drives/allows you to split the logics and presentation layers, and to split the views and the models into hierarchies of classes - the opposite direction you seemed to be exploring. > 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). > 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. r. _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
