tim.thel...@gmail.com wrote:
I think this would be better solved by moving fully to an OOP model. That is, I would have a SubuserProgram class which had methods such as "install", "describe", "isInstalled"...
This wouldn't necessarily be better. Don't be taken in by the "everything is better as a class" kind of dogma that seems to prevail in some circles. If all you do is take a bunch of module-level functions and put them into a single class, you haven't really changed anything. It's still the same design, you've just arranged the source differently. There are a couple of good reasons for turning a function into a method. One is if it embodies implementation details that you want to keep separated from the rest of the program. But if *all* of your code is inside the class, there isn't any "rest of the program" to keep it separate from. Another is if you want to be able to override it in subclasses. If there were different kinds of SubuserProgram that needed to be installed in different ways, for example, it would make sense to structure this as a collection of classes with an install() method. But even then, you don't have to put all the installation code in the classes -- the methods could just be stubs that call out to different module-level functions if you wanted. A reasonable compromise might be to keep the *data* assocated with a SubuserProgram in a class, maybe together with a few methods that are tightly coupled to it, but have the major pieces of functionality such as install() implemented by separate functions that operate *on* the class, rather than being inside it.
Currently, I have these functions logically organized into source files, each between 40 and 170 LOC.
That's quite small as these things typically go. You can afford to make them somewhat larger; I tend to find that files start to get unwieldy around 1000 lines or so. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
