Announce: wxPython 2.5.1.5

wxPython Users
1

Roger Binns wrote:

I'm pleased to announce the 2.5.1.5 release of wxPython,

Robin,

Do you expect the 2.5.x stuff to be used mainly by developers
to stress, report bugs etc in preparation for 2.6, or
do you expect us to actually deploy our applications with
it?

I think that for the most part it is in good enough shape to deploy with. Being an "unstable" release doesn't mean that it is more buggy or crash prone[1], just that the APIs are allowed to change between releases. IOW, all releases in the 2.4.x series and eventually the 2.6.x will normally not have API changes, (and from the C++ perspective they will also compatible at the binary level too.) On the other hand, the next 2.5 release will probably have slightly different APIs or behaviors as things mutate into the eventual 2.6. To summarize:

  "stable" --> APIs shouldn't change, binary compatible
  "unstable" --> APIs allowed to change.

[1] In fact, probably the opposite in most cases because some types of bugs are easier to fix when not constrained by keeping things fully compatible.

So, I think that the answer really needs to be answered on a case by case basis. If you are distributing your apps as binaries with py2exe or similar or are otherwise including wxPython then moving to 2.5 to get some of the new features and such would probably make a lot of sense. If your users are using your app with a separately installed wxPython then you'll probably want to let them know which version your app is written for and then decide for yourself which version that will be.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

2

I think that for the most part it is in good enough shape to deploy
with.

I do a release of my app every two weeks on Linux, Windows and
Mac. It is distributed as "binary" with the wx libraries and
Python interpretter included.

Are all the platforms ok? [NB one of my platforms is MacOS X 10.2
with a Python 2.3 interpretter] The one thing I won't do with my
app is support both 2.4 and 2.5 at the same time. I want it clean
and a one time transition.

I don't particularly mind gentle API changes as long as they
are for the better :slight_smile:

The main thing I am scared of is doing the transition, which will
probably take a week or two, and then hitting issues so bad that
everything has to be backed out.

From your advice it would seem worthwhile moving over relatively

soon based on my release cycle (assuming MacOS X 10.2 isn't an
issue).

Another problem is that you can generally only have one version
of wxPython on a machine at a time. If any of my other developers
work on other projects they really won't want to have to cope
with two versions simultaneously, or of having to compile wxPython
themselves to put in a custom location.

Maybe it is possible to name the package wx25 or something like
that? The I can put 'import wx25 as wx' at the top of each
file to select version.

Roger

3

It is probably worth stating that wxPython 2.4.2.4 is the last 2.4.x release that will be made. That means if there is a show stopper bug for you in wxPython 2.4.2.4 and you can't do a workaround in your code, then you're probably out of luck without moving to wxPython 2.5.x

If you use any tools that rely on wxPython or generate wxPython code like Boa, wxDesigner, wxGlade, SPE, and PythonCard then you need to make sure that those tools will support whichever version of wxPython you want to work with.

If you are using Mac OS X, I definitely recommend moving to 2.5.x, but you should probably be prepared for even more frequent Mac releases (versus Windows or Linux) in the coming months as the underlying wxMAC code is seeing a lot of changes and fixes.

The new style class changes in wxPython 2.5 mean that you have to look closely at your code if you are doing anything with __getattr__, __setattr__, or any kind of introspection involving wxPython classes. Most programs won't be impacted, but I suggest testing, other changes mentioned in the migration guide are probably easier to spot because your program will throw a runtime error.

In the case of PythonCard, maintaining support for both wxPython 2.4.x and 2.5x is enough of a pain, that after release 0.7.3 I suspect I'll recommend that we abandon wxPython 2.4.x and only support 2.5.x and higher for PythonCard 0.8 and higher; PythonCard 1.0 is coming this spring. Furthermore, the version requirement will keep getting bumped as API changes are made in wxWidgets/wxPython.

ka

···

On Apr 2, 2004, at 12:24 PM, Robin Dunn wrote:

Roger Binns wrote:

I'm pleased to announce the 2.5.1.5 release of wxPython,

Robin,
Do you expect the 2.5.x stuff to be used mainly by developers
to stress, report bugs etc in preparation for 2.6, or
do you expect us to actually deploy our applications with
it?

I think that for the most part it is in good enough shape to deploy with. Being an "unstable" release doesn't mean that it is more buggy or crash prone[1], just that the APIs are allowed to change between releases. IOW, all releases in the 2.4.x series and eventually the 2.6.x will normally not have API changes, (and from the C++ perspective they will also compatible at the binary level too.) On the other hand, the next 2.5 release will probably have slightly different APIs or behaviors as things mutate into the eventual 2.6. To summarize:

  "stable" --> APIs shouldn't change, binary compatible
  "unstable" --> APIs allowed to change.

[1] In fact, probably the opposite in most cases because some types of bugs are easier to fix when not constrained by keeping things fully compatible.

So, I think that the answer really needs to be answered on a case by case basis. If you are distributing your apps as binaries with py2exe or similar or are otherwise including wxPython then moving to 2.5 to get some of the new features and such would probably make a lot of sense. If your users are using your app with a separately installed wxPython then you'll probably want to let them know which version your app is written for and then decide for yourself which version that will be.

4

Roger,

I think you should ask yourself a few questions first. Do you need to deploy in 2.5 for some reason? is there something about 2.4 that's causing issues? Is there a feature in 2.5 you simply can't live without? W/out compelling reason to shoot a hole in your foot, should you do it anyway?

2.5 has just been released. By the sounds of it, there's a lot of voodoo in the whoodoo that Dunn-bot has been up to. Unless Robin is far more perfect than I can imagine :o, bugs will creep out, especially since this is an expermental, Open-source, odd numbered, point release.

I suspect Robin would be glad to hear of a production system running 2.5 already, but doubt he would expect anyone to take a plunge like that w/out exercising caution.

IMO it's not prudent to release any system into a production environment w/out extensive testing on a new release of anything, exprimental or not. Infact, I'd wait for at least 3 days before I started asking these questions... :slight_smile:

-Joe

Roger Binns wrote:

···

I think that for the most part it is in good enough shape to deploy
with.
   
I do a release of my app every two weeks on Linux, Windows and
Mac. It is distributed as "binary" with the wx libraries and
Python interpretter included.

Are all the platforms ok? [NB one of my platforms is MacOS X 10.2
with a Python 2.3 interpretter] The one thing I won't do with my
app is support both 2.4 and 2.5 at the same time. I want it clean
and a one time transition.

I don't particularly mind gentle API changes as long as they
are for the better :slight_smile:

The main thing I am scared of is doing the transition, which will
probably take a week or two, and then hitting issues so bad that
everything has to be backed out.

From your advice it would seem worthwhile moving over relatively

soon based on my release cycle (assuming MacOS X 10.2 isn't an
issue).

Another problem is that you can generally only have one version
of wxPython on a machine at a time. If any of my other developers
work on other projects they really won't want to have to cope
with two versions simultaneously, or of having to compile wxPython
themselves to put in a custom location.

Maybe it is possible to name the package wx25 or something like
that? The I can put 'import wx25 as wx' at the top of each
file to select version.

Roger

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

5

Roger Binns wrote:

Another problem is that you can generally only have one version
of wxPython on a machine at a time. If any of my other developers
work on other projects they really won't want to have to cope
with two versions simultaneously, or of having to compile wxPython
themselves to put in a custom location.

Maybe it is possible to name the package wx25 or something like
that? The I can put 'import wx25 as wx' at the top of each
file to select version.

YES! PLEASE!

I've been thinking about this for a while, and it would be a GREAT idea to be able to have multiple versions installed at once. I use that feature all the time with Python itself. If I have an app working on Python2.2, I use: #!/usr/bin/env/python2.2 at the top, and I can forget about it. when I add python2.3 later, all the scripts that I have working with 2.2 just keep working. Until recently RedHat required "python" to be 1.5.6., so I had to specify a version number on teh #! line anyway.

As for OS-X, I've just discovered that a small wxPython app built with BundleBuilder is over 22MB ! It can be compressed to about 6MB for distribution, but that's still pretty big. On my Linux system, I have a whole bunch of small utilities that I start up with the above #! line. I'd love to be able to distibute them on OS-X to my collegues without each one being 22MB. A bundlebuilder "Applet" would be great, but then if I write a new one with an upgraded wxPython, I would need to upgrade them all, and have the users re-install them all. I'd much rather just distribute the new applet with the new wxPython, and not have anything existing break.

I've tried just renaming wx and wxPython, but both of them seem to be imported in enough other places that that doesn't work. It probably wouldn't be hard to fix it everywhere, however. The lib, and demo and all that get delivered together.

This really is analogous to shared libraries...they need to have version numbers specified so that multiple versions can coexist.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

6

I think you should ask yourself a few questions first. Do you need to
deploy in 2.5 for some reason? is there something about 2.4 that's
causing issues? Is there a feature in 2.5 you simply can't live
without? W/out compelling reason to shoot a hole in your foot, should
you do it anyway?

There is nothing I need. But some things would be nice, like being able
to select text in HTML, or a help controller than supports CHM format
on all platforms. The other reason for doing it would be to make
2.6 better. If I find and report problems now, they are far more
likely to be fixed than when 2.6 is released.

2.5 has just been released.

That isn't quite true. There have been several releases in the 2.5 series
already.

I suspect Robin would be glad to hear of a production system running 2.5
already, but doubt he would expect anyone to take a plunge like that
w/out exercising caution.

My project is at version 0.7 and the worst thing that would happen
is several weeks wasted porting over to 2.5 and then throwing it
away.

Roger

7

If you are using Mac OS X, I definitely recommend moving to 2.5.x, but
you should probably be prepared for even more frequent Mac releases

It is actually the Mac guy on the project who has been pushing
hardest for moving to 2.5. I don't particularly care, but it
would be nice to contribute back to wxPython by finding and
reporting any issues.

The new style class changes in wxPython 2.5 mean that you have to look
closely at your code if you are doing anything with __getattr__,
__setattr__, or any kind of introspection involving wxPython classes.

The only thing I do is in one piece of code where I figure out
the class of an event (between two possible candidates). I generally
stay away from the clever tricks in Python, unless they
very appropriate.

Roger

8

It is a no-brainer on Windows, especially if you only want to keep two versions around. In my case, I have a swapwx.py script which I posted a while ago to wxPython-dev that checks the version via an import, then renames the existing wx and wxPython dirs before renaming the other dirs to be active. For example, if 2.4.2.4 is active, the dirs will be renamed wx24 and wxPython24 and then the wx25 and wxPython25 dirs get renamed to wx and wxPython. But wxPython on Windows is self-contained and doesn't have libs spread all over the place so I don't have this working on Mac OS X yet and I don't use Linux, but I expect it has the same kinds of problems.

ka

···

On Apr 2, 2004, at 1:50 PM, Chris Barker wrote:

Roger Binns wrote:

Another problem is that you can generally only have one version
of wxPython on a machine at a time. If any of my other developers
work on other projects they really won't want to have to cope
with two versions simultaneously, or of having to compile wxPython
themselves to put in a custom location.
Maybe it is possible to name the package wx25 or something like
that? The I can put 'import wx25 as wx' at the top of each
file to select version.

YES! PLEASE!

I've been thinking about this for a while, and it would be a GREAT idea to be able to have multiple versions installed at once. I use that feature all the time with Python itself. If I have an app working on Python2.2, I use: #!/usr/bin/env/python2.2 at the top, and I can forget about it. when I add python2.3 later, all the scripts that I have working with 2.2 just keep working. Until recently RedHat required "python" to be 1.5.6., so I had to specify a version number on teh #! line anyway.

As for OS-X, I've just discovered that a small wxPython app built with BundleBuilder is over 22MB ! It can be compressed to about 6MB for distribution, but that's still pretty big. On my Linux system, I have a whole bunch of small utilities that I start up with the above #! line. I'd love to be able to distibute them on OS-X to my collegues without each one being 22MB. A bundlebuilder "Applet" would be great, but then if I write a new one with an upgraded wxPython, I would need to upgrade them all, and have the users re-install them all. I'd much rather just distribute the new applet with the new wxPython, and not have anything existing break.

I've tried just renaming wx and wxPython, but both of them seem to be imported in enough other places that that doesn't work. It probably wouldn't be hard to fix it everywhere, however. The lib, and demo and all that get delivered together.

This really is analogous to shared libraries...they need to have version numbers specified so that multiple versions can coexist.

9

As for OS-X, I've just discovered that a small wxPython app built with
BundleBuilder is over 22MB ! It can be compressed to about 6MB for
distribution, but that's still pretty big.

These are the sizes for my program. The distribution is identical for
all platforms, except Windows has a second copy of the help file in
CHM format(1.1MB) and a binary (1.6MB).

  6310066 bitpim-0.7_test7-0.i386.rpm # cx_Freeze + rpm
  5905993 bitpim-0.7-test7-setup.exe # py2exe + InnoSetup
  8078526 JAGUAR-bitpim-0.7-test7.dmg.gz # BundleBuilder + dmg
  6843640 PANTHER-bitpim-0.7-test7.dmg.gz # BundleBuilder + dmg

Roger

10

Kevin Altis wrote:

It is a no-brainer on Windows, especially if you only want to keep two versions around. In my case, I have a swapwx.py script which I posted a while ago to wxPython-dev that checks the version via an import, then renames the existing wx and wxPython dirs before renaming the other dirs to be active. For example, if 2.4.2.4 is active, the dirs will be renamed wx24 and wxPython24 and then the wx25 and wxPython25 dirs get renamed to wx and wxPython. But wxPython on Windows is self-contained and doesn't have libs spread all over the place so I don't have this working on Mac OS X yet and I don't use Linux, but I expect it has the same kinds of problems.

I havn't tried on OS_X yet, but I have a little shell script that creates sym links to either wx2.4 or wx2.5, depending. It works just fine, and is great for development.

It sounds like you've got a little hook that you can put in the top of a python app, so that it will select for itself, whihc one it wants. That's all well and good, but I could forsee a mess if you have more than one app running at a time, and they want different versions. Besides, I don't want to have to put this special code in my scripts, I want to be able to simply write:

import wx25 as wx

I way be missing something here, but it seems like that sould be easy, and work well. There would be a link from wx to the "prefered versions" so anyone that wasn't using multiple versions would never notice.

If you look at how Python is distributed, it's exactly like this. If wxPython releases were in sync with python releases, there wouldn't be a problem, but they aren't.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

11

Roger Binns wrote:

I think that for the most part it is in good enough shape to deploy
with.

I do a release of my app every two weeks on Linux, Windows and
Mac. It is distributed as "binary" with the wx libraries and
Python interpretter included.

Are all the platforms ok? [NB one of my platforms is MacOS X 10.2
with a Python 2.3 interpretter]

There are some big internal changes going on right now with wxMac, so a few known bugs there did not get resolved because it had to wait for the big changes to be done. That said, I think it is in lots better shape now than 2.4.2.4, and after the dust settles on the new changes it shoudl be even better. The other platforms should be okay too.

The one thing I won't do with my
app is support both 2.4 and 2.5 at the same time. I want it clean
and a one time transition.

Since you are bundling everything then there is probably no reason to worry about supporting both verisons.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

12

I too might be missing something here BUT why not use "SET PYTHONPATH" to
select wx25?
I mean.... the changes in API have to be fixed by hand, is not enough to
say

import wx25 as wx

from what I've seen, there are a lot of methods/functions that got their
parameters constricted (less parameters, more tuples) those things will
throw an error no matter what clever trick you do to change the import...

Note that I don't want my project to be "portable" between versions.
What I want is for the developers on my project to be able to work
on other projects, and if both use different versions of wxPython
for it to work well. The API changes etc are not relevant.

Although Pythonpath can be used, it would require that after installing
wxPython, various files and directories have to be moved around
(as root on Linux), and the environment variables will always have
to be set. That is a lot of extra hassle for the developers.

Roger

13

Phoenix/README.rst at master · wxWidgets/Phoenix · GitHub

This document describes how I handle multiple verisons on unix systems,
one installed from the standard binaries, and one (or more) built for
development and testing.

The last thing I will do is require developers on my project
to have to build their own version of wxPython!

The ideal solution for me is that developers on my project
can install as many versions of wxPython from the standard
website as they want. In my code I then select the correct
version using 'import wx25 as wx'

That won't interfere with other projects, and won't have
random dependencies on environment variables, or any
potential for error.

Roger

14

Peter Damoc wrote:

I too might be missing something here BUT why not use "SET PYTHONPATH" to
select wx25?

This does sound like a good idea, but...

I mean.... the changes in API have to be fixed by hand, is not enough to
say
import wx25 as wx

Not the way it is currently set up, but if ALL of wxPython (demo, libs, etc) was set up this way, I don't see why it wouldn't work.

from what I've seen, there are a lot of methods/functions that got their
parameters constricted (less parameters, more tuples) those things will
throw an error no matter what clever trick you do to change the import...

yes, the code has to be different for different versions of wxPython. That's the whole point of this discussion.

Note that I don't want my project to be "portable" between versions.
What I want is for the developers on my project to be able to work
on other projects, and if both use different versions of wxPython
for it to work well. The API changes etc are not relevant.

Me too, but I want USERS to be able to have different versions installed as well.

"extra hassle for the developers" well if they cannot take this kind of hassle... I mean what hassle? a couple of minutes spent ONE TIME cooking a script that fixes the enviroment? come on.

I agree here, the extra hassle for developers is no big deal, However, I want it to be easy for users too, so it's more of deal. I'm thinking of making the path addition in my Python code instead:

import sys
for p in sys.path:
     if p[-13:] == "site-packages":
         sys.path.append(p[:-13]+"wxPython/2.5/")
import wx

This seems to work, but it requires a custom install of wxPython, and now I have to mess with the demo to get it to work.

In all I think this is very important, and should be solved by the standard way wxPython is distributed, not by each of us coming up with our own custom kludge.

Robin, am I missing something here? why not put a version number in the name? It seems like we are doing the equivalent of distributing a shared libary with no version number. There's a reason the phrase "dll hell" was coined!

-Chris

···

On Sat, 3 Apr 2004 09:49:19 -0800, Roger Binns <rogerb@rogerbinns.com> > wrote:

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov