Yet another Philosophy Question: LambTracker Desktop is currently set up with multiple top-level windows to isolate the UI and code for each major “module”. There are 3 of these modules, Animals, People and Population Analysis. In both Animals and People there are 2 windows, Search and Reports where of the 4 frames within those 2 windows two frames are the same. As in same display of labels, same checkboxes, same combo boxes and buttons with the same functionality.
Clearly duplicating the code in each window class is stupid. That makes the entire application much more difficult to maintain and more prone to odd errors due to slight differences between the 2 window versions that are likely to creep in.
So what is the best way to put that code into a separate thing? Should that shared code be in another file that I import? Or should it just be another in-line class definition that gets called with various parameters when I create the window object?
Is there a performance issue doing one way vs another?
Is one way more Python like?
For folks with experience with complex programs what have you found works in practice, all academic suggestions aside.
import statements can be executed just about anywhere. It’s often useful to place them inside functions to restrict their visibility and/or reduce initial startup time. Although Python’s interpreter is optimized to not import the same module multiple times, repeatedly executing an import statement can seriously affect performance in some circumstances.
My preference would be to have it in it’s own file
Given that you have a window layout that is the same in more than one place, I’d create a function to draw that window.
def draw_SearchReportWindow(...);
I would store that function in a way that it is accessible as a general-purpose utility function. I would replace all blocks of supposedly the same code across all other modules with a call to that function.
I would pre-load the general purpose module in the header of the main routine.
To be fair here, I am not at the level in python to appreciate the utility of classes (let alone in-line classes). In my Fortran-ish / javascript-ish mind, I tend first to create functions (sub-routines) to do things.
I’m not completely sure whether this answers your question, but are you familiar with the Model-View-Controller design pattern? Designing with this pattern (if you’re not already) may provide you with more obvious ways to separate your code.
I think what you probably want is to extract the duplicated code (yes, it’s stupid to have duplicated code, for just the reasons you’ve mentioned) into one or more classes which you then import and instantiate in each of those two modules.
hmm, my previous answer seems to be MIA. But yes. In general I am trying to produce orthogonal code so that changes to one layer will not affect another but in practice I’m not skilled enough in Python to make it all work.
I’m also a huge fan of the Ready, Fire, Aim method of programming. Because no code survives first contact with the sheep it’s a lot more efficient to get a test or demo case working good enough, go run it with live data collection on live animals and then refine it.