The first thing you need to do is import the main wxPython package, which is named wx:
Once that package is imported, you can refer to wxPython classes, functions, and constants using the wx package name as a prefix, like this:
OLD STYLE During the writing of this book the name of the wxPython package IMPORTS changed. Since the old naming convention is still supported, you will probably encounter wxPython code written in the old style. So, we'll digress briefly to explain the older style and why it was changed. The old
JARGON: IT LOOKS
package name was wxPython and it contained an internal module named wx. There were two common ways to import the needed code— you could import the wx module from the wxPython package:
from wxPython import wx #DEPRECATED—DON'T DO THIS ANY MORE
Or, you could import everything from the wx module directly.
from wxPython.wx import * #DEPRECATED—DON'T DO THIS ANY MORE
Both import methods had serious drawbacks. Using the second method of import * is generally discouraged in Python because of the possibility of namespace conflicts. The old wx module avoided this problem by putting a wx prefix on nearly all of its attributes. Even with this safeguard, import * still had the potential to cause problems, but many wxPython programmers preferred this style, and you'll see it used quite often in older code. One downside of this style was that class names began with a lowercase letter, while most of the wxPython methods begin with an uppercase letter—the exact opposite of the normal Python programming convention.
However, if you tried to avoid the namespace bloat caused by import * by doing from wxPython import wx, you now had to type "wx" twice for each class, function, or constant name—once as the package prefix and once as the "normal" prefix, such as wx.wxWindow. This got old fast. Many wxPython programmers saw this dilemma as a wart that should be removed, and eventually, it was. If you're interested, you can search the wxPython mailing list archives to read more of the details surrounding this change.
One more thing to know about importing wxPython: you must import wx before you import anything else from wxPython. In general, the order of imports in Python is irrelevant, meaning you can import modules in any order. However, wxPython, although it looks like a single module, is actually a complex set of modules (many of which are automatically generated by a tool called the Simplified Wrapper and Interface Generator, or SWIG) that wrap the functionality provided by the underlying wxWidgets C + + toolkit (we'll discuss wxWidgets in more detail in section 1.7). When you import the wx module for the first time, wxPython performs some initialization that is vital to other wxPython modules. As a result, some of the wxPython subpackages, such as the xrc module, might not work properly unless the wx module has already been imported:
import wx from wx import xrc from wx import html
# Always import wx before
# any other wxPython packages,
# just to be on the safe side.
This requirement applies only to the wxPython modules; you can still import other Python modules as you always have, and those modules can be imported before or after the wxPython modules. For instance, this example is valid:
import sys import wx import os from wx import xrc import urllib
Was this article helpful?