Hi,
[snip]
The other problem I have as an inexperienced OOP and Python programmer is what form the reactor/loops take; meaning do I make one reactor a process and one a thread, use 2 seperate processes and IPC or the broader RPC or go lower level and use just sockets, or whatever you get the idea. I know that wxPython needs to be the primary process. But if I wanted to replace that GUI package, would the next GUI package need to take a different place in the looping parent/child structure. Again… too much thinking, (ie back to the wx.Frame that does it all).
Yeah, the problem is mostly over-thinking the level of abstraction. 
It will just give you a headache. Programmers are taught to think in abstractions, but there’s a point where abstractions lose any practical benefit and actually cause you to come up with overly complex designs to solve simple problems. Even MVC vs. MVP seems to me to be based on a misunderstanding of what MVC is. MVP, from what I’ve read of it, reads like someone learning MVC by reading articles, misunderstanding it, and creating MVP to ‘fix’ what they saw was wrong with MVC, which IMHO is just re-creating MVC and calling it by another name. I will use the term MVC, but if you want to consider what I’m saying MVP that’s fine.
Here’s an easy to understand way of writing more MVC-compliant apps with wxPython. Take your wx.Frame subclass with everything in it, convert it to an wx.EvtHandler subclass that takes a wx.Frame as an argument (along with any data objects you need). Then replace any calls to wx.Frame API from self.Whatever to self.frame.Whatever. Then, when your app starts, initialize your frame, your data objects, and then initialize your EvtHandler subclass and pass them in, like so:
class MyController(wx.EvtHandler):
def __init__(self, frame, data):
self.frame = frame
self.data = data
# create child controls
self.button = wx.Button(self.frame, -1, "Load")
...
# bind events
self.button.Bind(wx.EVT_BUTTON, self.OnLoadClicked)
def OnLoadClicked(self, event):
self.LoadData()
def LoadData(self):
self.data.load_data()
# populate wx.Frame controls with data
class MyApp(wx.App):
def OnInit(self):
frame = wx.Frame(None, -1, "MVC Frame")
data = MyDataStructure()
self.controller = MyController(frame, data)
# eventually...
# self.controller1 = DataViewController(frame, data)
# self.controller2 = AnimationController(frame)
# etc.
frame.Show()
return True
Now all your code is no longer in a wx.Frame subclass. And you’ll note, a small app written this way will have only a few more lines of code than a traditional, all in wx.Frame app does. People way overestimate what is required or expected of MVC abstraction. They think that if you use MVC you must break everything into tiny, tiny bits. You don’t need to. A small MVC app will look much like a traditional wx app does, as you can see above. However, as the app grows, this model makes refactoring and reuse simpler. When you add new code, instead of having only one choice, that is, to just stuff it in the wx.Frame subclass, you can choose - if you feel the code’s reusable, you can make a new, shareable controller for it. If not, you can just put it your primary controller, just the same as you’d do if your wx.Frame was the event handler. You may always do it that way. But the key is that you have that choice.
It’s really that simple. Move your code from a wx.Frame subclass into a wx.EvtHandler subclass and you’re doing all that’s required. You may never make more than one Controller for your app. It’s okay. You aren’t angering the MVC gods by doing so. 
The point of adopting MVC is that it facilitates creating discrete controllers for discrete behaviors when that is the best approach, though small apps may never need to.
Anyway, I do appreciate that until the toolkit itself considers adopting some of these ideas for its code, it’s hard to get a solid grasp of the concept, and it feels like you’re fighting the toolkit to use it. Even as I promote MVC, I myself find it hard to give up on the traditional way of writing wxPython code since I’m working with a lot of legacy code or code written by others. When you see and work with that code all the time, the path of least resistance is to simply stick with that model for everything. However, since I code with other toolkits, I also know the pitfalls of the wx approach, and I don’t think it’s good to rest on one’s laurels and stop looking for better ways of doing things. I should probably at least clean up my InlineTextSearchController and contribute it, so that people who need inline text search can use it and get an idea of how controllers work.
Regards,
Kevin
···
On Sep 24, 2011, at 10:33 PM, Dev Player wrote:
I needed none of these questions answered if I didn’t mind programming in however the situation called for for each script/app whatever. But if I wanted to develope apps with reusable interfaces, and standarize my tools it seemed prudent to at least look into all this.
I can also ponder these thoughts because at this time I program Python on as purely reacreation exercise. Maybe these words will actually produce some useful insight.
–
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en