Hi,
win98, Py234
My comments are refering to the versioning mechanism and not
to the intrinsic wxPy lib, which seems to work smoothly.
- The real good surprise is that I had to download only a
light runtime lib. (5 Mb instead of 10 Mb)
- Installation on win98 without any problem.
- Glad to see the word "ansi" instead of "ascii".
- I tweaked the wx (2.5.2.8) dir and created a wx-2.5.2.8-msw-ansi
dir for testing purposes. Having now 2 wxPy versions( and no more
a wx dir), I played with "wxversion.require()" on some test
applications. It was perfectly working. 
- My first frustrating experience is coming from the require
version argument. It is too complicated, in the sense it is too
sophisticated. I undestand how it works, but in a pratical
situation, I find it confusing. With only two versions, I never
knew what I was doing. Ex: 2.5.2.8 -> uses 2.5.2.8; 2.5 -> uses
2.5.3.0p*, 2.5.3.0 -> does not work, but 2.5.3 is working, while
2.5.2 is not working.
If I had to give an advice to an end (newbie) user, I would
suggest to always use a 4 digits tag. It seems the proposal
from Christoph Barker (?) to have all the "allowed" versions
in a list is finally not a bad idea. It has the merit of
simplicity and clarity.
- The naming scheme of the different wxPython dirs is not
satisfying. The use of dot(s) "." inside a dir name is simply
a *huge* mistake. On win platforms, the dot is the seperation
mark between a filename and its extension. No more no less.
There are so many tools that use this convention (eg using a
dot as indicator between dir names and filenames).
Note that Python itself is handling this properly. It is
installed in a x:\Python23 dir and not in a x:\Python 2.3 dir.
Even the os.path module (split* functions) is using this property,
understand considering the dot as *the* file extension separator.
(For the story, Ruby is installed in a ruby-1.8.1 dir, the
mailing lists are full of complaints about this).
The use of wx-230-msw-ansi should be prefered over a
wx-2.3.0-msw-ansi.
In fact, inserting a dot in a dir name is not only breaking
the windows convention, but it is also no more compatible
with Python, see Python manuals, 6.1.6 Miscellaneous System
Information
I do not know a third party product, even in the open source
world (execept ruby), that is breaking this convention.
- Small bug(?) in wxversion.py. The ..\site-package\wx-** is
registrated twice in sys.path. The duplication is due to *.pth
file and the internal wx dir searching, when updating the sys.path
or something like this. Easy to fix.
- I have a serious concern with py2exe. py2exe does not like
wxversion.py. Py2exe is working, it is building the exe. Later,
the executable is not recognizing the "wx path". I do not think,
that this is a py2exe bug, but more an unpleasant side-effect.
Anyway, an end user with only the latest wx release may be
affected by this.
Regards.
Jean-Michel Fauth, Switzerland.