You aren't required to create your own wx.App subclass. You usually will want to do so to be able to create your top-level frame in the OnInit() method. But there is nothing stopping you from creating the frame outside of the application definition in some other part of calling script—the most common alternate place is the
_main_clause. The only restriction is that your wx.App instance has to have been created first. Generally, it is only a good idea to avoid creating a wx.App subclass if there's just one frame in the system, and therefore the application setup is trivial. In such a case, wxPython provides the convenience class wx.PySimpleApp. The class provides a skeleton OnInit() method, and is defined as follows:
def _init_(self, redirect=False, filename=None, useBestVisual=False, clearSigInt=True):
wx.App._init_(self, redirect, filename, useBestVisual, clearSigInt)
def OnInit(self): return True
It doesn't get much simpler than that. A sample usage of wx.PySimpleApp might look like this:
app = wx.PySimpleApp() frame = MyNewFrame(None) frame.Show(True) app.MainLoop()
In the first line of this snippet, you create the application object as an instance of wx.PySimpleApp(). Since we're using the wx.PySimpleApp class, we don't have a custom OnInit method, so we define a frame in the second line of the snippet— since it has no parent specified, it's a top-level frame. (Obviously, the MyNewFrame class needs to be defined somewhere.) The third line of the code shows the frame, and the last line calls the application main loop, and we're good to go.
As you can see, using wx.PySimpleApp allows you to run your wxPython program without creating your own custom application class. You should only use wx.PySimpleApp if the application is, well, simple, and doesn't need any other global parameters.
NOTE Naming Conventions—While wxPython does a fantastic job of simplifying a complex C++ toolkit, the C++ origins of the tool do leak through in spots. One of the most noticeable examples of the C+ + heritage has to do with naming conventions. In Python, method names usually use the lower_case_ separated_by_underscores or the lowerCaseInterCap style. However, the C++ convention which wxWidgets uses for methods is the UpperCaseInterCap style. This can be jarring if you are used to the Python style. For consistency's sake, it is recommended that you use the wxWidgets style in your wxPython classes. (Of course, you'll need to use it if you want to override wxWidgets methods).
Also note that the wxPython classes use explicit Get and Set methods for properties. That's more of a C++ style because most Python programs wouldn't define special accessor methods for simple cases.
The data members of the C + + classes are private—in most cases you must access the data of a wxPython class by using the access methods, you cannot use bare attribute names.
Was this article helpful?