2009/11/19 Kingsley Reuben:
>
> This post is regarding communication between Python and wxWidgets.
>
> After much analysis, I've decided to use Python 3.1 and wxWidgets
> 2.8.10 for development of our appln.
Is your analysis telling you why/how Python 3.X is in any way better
than Python 2.5/2.6? Honestly, I can't see a single benefit.
> Due to the unavailability of
> wxPython for Python 3.1, we are stuck up with making wxWidgets work
> with Python 3.1.
>
> It will be of great help for me, if am properly directed on how to
> bind wxWidgets with Python.
It's not that easy. Currently wxPython supports up to Python 2.6, and
I don't think anything has been done for the Python 3.X series. After
all, Python 2.5/2.6 will be maintained and bug-fixed for many years to
come, so why bother now if there are no real incentives to switch to
Python 3?
In any case, I believe Robin will accept any patch that makes wxPython
more happy with Python 3, although I suspect that the task of porting
the pure-Python code in wx.lib and the SWIG interfaces for wxWidgets
is close to immense.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
http://thedoomedcity.blogspot.com/
This is probably mostly a matter of running the Python script 2to3 on
the Python scripts in wxPython/wx/lib, and sending patches for
whatever issues it raises. The tricky part here is that we'd probably
like to keep Python 2.4+ support too, so some of the changes 2to3
makes will probably need to be put in version checks rather than just
applying the change 2to3 did.
> Yes, PLEASE. For those of us supporting large existing projects, losing
> Python 2.x support in wxPython any time in the near future would be
> catastrophic.
Well, the question here is not whether to drop support for 2.* -- I
don't think anyone would suggest that for a good long while.
The question is:
Is the py3k port done as a branch, so that there would then be two
versions of the wxPython code, or do we try to keep a single code base.
Also, how far back do we need to support? With 2.6 at 2.6.4, and now
3.1, and 2.6 being the one to support in the long run, I think trying to
keep compatibility all the way from 2.4 to 3.* in one code base is
pushing it.
So I'd suggest either branching the 3.* code, or creating a 2.6+3.* code
base. 2.6 has features to make this possible, that older versions do not.
I actually think that branching makes the most sense -- it would be nice
to have the freedom to do things differently -- maybe very differently,
like using Cython, rather than SWIG, or who knows what? One advantage to
Cython is that it does support both 2.6 and 3.* out of the box, so you
can have one extension code base for both (though I suppose SWIG
supports that too).
Really though, these are decision that are going to be made by whoever
really puts the work in!
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception