This document will help explain some of the changes in wxPython 2.9 since the 2.8 series that may cause some issues when migrating existing applications to the new version of wxPython. For a list of new things that have been added to wxPython, and the not so major changes that are not documented here, be sure to read the CHANGES file like usual.
Over the years there have been a number of aliases that I added to wxPython that seemed like a good idea at the time, but really just added to the clutter. Many of these have been removed in the 2.9 release series. Unfortunately a list of removed names wasn't kept, but they should be obvious when you run into them. For example there were some aliases for the various wxColour functions, etc. that allowed the use of the American spelling. So if you get an exception about wxColor not being found, just add the extra 'u' to the name and you'll be all set.
The grid sizer classes now assert if you specify both the number of rows and the number of columns in the constructor, and you add more items than will fit in the specified number of rows. You can avoid this assertion simply by specify only the number of columns and let the sizer work out the number of rows for itself based on the number of items added to the sizer. For example, instead of:
sizer = wx.FlexGridSizer(2, 4, 5, 5)
You can use:
sizer = wx.FlexGridSizer(cols=4, hgap=5, vgap=5)
When items in a box sizer have a proportion greater than zero that indicates that the item should get a portion of the space that is still available after non-proportional items have been given space. Prior to 2.9.1 that space was allocated solely based on the proportion values. Starting with 2.9.1 the minimum or best size of the items is checked first, and proportional items will not be made smaller than their minimum or best size.
There is now a script called build-wxpython.py that can be used to build both wxWidgets and wxPython with all the correct options and flags. See wxPython/docs/BUILD.txt for details.
The ANSI builds of wxPython are finally dead and gone. Long live Unicode!
If you've always used the ansi builds in the past, or are not familiar with working with Unicode objects, the recommended way to deal with this change is to only use encoded string objects at the I/O points of your application, (e.g., when reading/writing the data to files or a database) and use Unicode objects everywhere else. If you have string literals in your code that are more than just ascii then add the "# -- coding: [codec name] --" line at the top of the file, and put a 'u' in front of the string's quotes. That way those literals will be Unicode objects from the beginning (compile-time) and won't need to be decoded at run-time.
This approach will also work in a 2.8 unicode build, so you can start preparing for the move to 2.9.x by making the changes now while still working with wxPython 2.8.
The remainder of this document describes some migration issues for Project Phoenix, which will one day replace the current wxPython implementation. These changes do not yet apply to any released version of Python and are currently provided for information purposes and for a glimpse into the future. For more information about Project Phoenix please see the ProjectPhoenix pages in the wiki.
Up to this point in order to support more than one of the versions of an overloaded C++ function or class method we have had to rename all but one of them. For example, for the wxWindow::SetSize method we have SetSize, SetDimensions, SetRect and SetSizeWH. One of the features of the new tools used for Project Pheonix is that we no longer need to do that and instead we can have just one function or method in the Python API and the propper version of the C++ function or method is chosen at runtime based on the types of parameters passed to the function. So in most cases the renamed versions of the overloaded functions have been removed and you can call the function with the same name as the C++ API.
This also includes the default constructor for all widget classes, used for the 2-phase create. Previously they were renamed to to be the class name with "Pre" prepended to it. For example, wx.PreWindow(), wx.PreFrame(), etc. Now in the Phoenix build of wxPython that is no longer neccessary and you can just call the class with no parameters like normal.
For those renamed items that are more commonly used I'll add some alias that will issue a DeprecationWarning for the first release or two after we switch over to the Phoenix version of the code, and then remove them in a later release.
As mentioned easlier, there are no longer separate ansi/unicode builds of wxPython starting with the first 2.9.x releases. All wxPython builds are now essentially the same as the old unicode builds. This means that all string objects passed to wx API functions or methods are converted to Unicode before calling the C++ function or method. By default wxPython would use the encoding specified by the locale that was current at the time of the import of the wx module.
However using the default locale could sometimes cause issues because it meant that slightly different encodings could be used on different platforms, even in the same locale, or the program could end up using an encoding in a different locale that the developer has not tested their code with.
Project Phoenix takes this Unicode simplification one step further by stipulating that only the utf-8 encoding will be used for auto-converting string objects to the Unicode objects that will be passed on to the wx APIs. If you need to deal with text using a different encoding then you will need to convert it to unicode yourself before passing the text to the wx API. For the most part this should not be much of a problem for well written programs that support Unicode because they will typically only convert to/from Unicode when reading/writing text to a file or database, and will use unicode objects throughout the rest of the code. The common exception to this is that string-literals are often used in the code for specifying labels, etc. for UI elements. If your text for the string literals in your code are all ascii or utf-8 then you should not need to make any changes at all. If you have literals with some other encoding then you'll want to deal with them one way or another.
wx.Platform has been renamed to wx.Port, and wx.PlatformInfo has been renamed to wx.PortInfo. The reason for this change is that wrappers for a C++ class named wxPlatformInfo have been added, and would have caused a name conflict if the old wx.PlatformInfo had not been renamed.
In related news, wx.USE_UNICODE and wx.__WXDEBUG__ have been removed.