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. 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.
I made the same post in wxWidgets forums. Am directed here.
regards,
Kingsley Reuben
Hi,
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/
Hi Kingsley,
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. 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.
Great, thanks! We can certainly help you to get started, but since no
one here has successfully built wxPython for Python 3 yet, you may run
into unexpected issues and it's hard to say how easy or difficult this
task will turn out to be.
To get started, I'd recommend you get the wxWidgets and wxPython code
from the WX_2_8_BRANCH in SVN via the instructions here:
http://wxpython.org/download.php#svnaccess
I'd recommend checking out wxPython inside of wxWidgets, so that the
wxPython tree lives in WX_2_8_BRANCH/wxPython. (Replace WX_2_8_BRANCH
with whatever folder name you used to check out wxWidgets.)
Then start by following the build instructions for the C++ portion of
the toolkit here: Phoenix/README.rst at master · wxWidgets/Phoenix · GitHub On Windows, make sure
you're using the same MSVC version used to build Python 3.
Once you get to the point of building wxPython bindings, you'll need
to make some changes to get things working with Python 3.1.
The task can basically be divided up into two parts:
1) Getting SWIG to generate Python 3 bindings for the C++ wrappers.
The first thing you'll need to do is get a SWIG that supports Python
3, meaning you probably want the latest release. Add -3 to the flags
passed to SWIG in the wxPython/setup.py build script if sys.version[0]
== '3'. You will also need to apply Robin's SWIG customizations to the
latest release, which can be found as a patch in the wxPython tree at
wxPython/SWIG/swig-1.3.29.patch. This may be a trivial task or it may
not; it's hard to know if the patch will apply cleanly to the latest
SWIG since it's been a long time, but if not, further customizations
may need to be made.
I'd also recommend that in wxPython/config.py, near the end, you add a
block like:
if sys.version[0] == '3':
GENDIR = os.path.join('py3', GENDIR)
PKGDIR = os.path.join('py3', PKGDIR)
so that you don't overwrite the Python 2 bindings and cause a ton of
svn conflicts in your files.
Once you have a properly built and running patched SWIG build, you
*should* be able to run setup.py as directed in the BUILD.html
instructions. Let us know if that works for you.
2) Get the Python code in the wxPython/wx/lib dir ready for Python 3.
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.
We would greatly appreciate it if you could submit patches for changes
you needed to make as you go along, so that everyone can benefit from
your work and so that we could get to the point of actively
maintaining Py 3 bindings.
Thanks,
Kevin
On Nov 19, 2009, at 4:02 AM, Kingsley Reuben wrote:
I made the same post in wxWidgets forums. Am directed here.
regards,
Kingsley Reuben>
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.
-Nat
On Thu, Nov 19, 2009 at 9:19 AM, Kevin Ollivier kevin-lists@theolliviers.com wrote:
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.
Thank You for this Information,
Cos I use Python 3.1 and cant do all as required to do in practicing with WxPython.
Please get back to us on when WxPython will be ready for Python 3.1
Best Regards…
On Thu, Nov 19, 2009 at 1:02 PM, Kingsley Reuben kings.reuben@gmail.com wrote:
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. 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.
I made the same post in wxWidgets forums. Am directed here.
regards,
Kingsley Reuben
–
Life is all About God ad You,
What Side are u with God?
Make the Best Choice Today
God loves You.
Hi Kevin,
That was really a great piece of information which is seldom available
anywhere else. I'll test the steps and let you all know the results
asap.
Kingsley Reuben
On Nov 19, 10:49 pm, "Hon. Toy Peters" <ibpe...@gmail.com> wrote:
Thank You for this Information,
Cos I use Python 3.1 and cant do all as required to do in practicing with
WxPython.
Please get back to us on when WxPython will be ready for Python 3.1Best Regards..
On Thu, Nov 19, 2009 at 1:02 PM, Kingsley Reuben <kings.reu...@gmail.com>wrote:
> 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. 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.> I made the same post in wxWidgets forums. Am directed here.
> regards,
> Kingsley Reuben--
Life is all About God ad You,
What Side are u with God?
Make the Best Choice Today
God loves You.
Nathaniel Echols wrote:
The tricky part here is that we'd probably
like to keep Python 2.4+ support too,
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
Chris.Barker@noaa.gov
Hi,
I tried the steps mentioned by Kevin but couldn't make wxPython as
Python 3.1 compatible.
Alternatively, PyQt4 is compatible with Python 3.1. It solved the
problem.
Great thanks to all who responded this post.
regards,
Kingsley Reuben
On Nov 19, 11:33 pm, Christopher Barker <Chris.Bar...@noaa.gov> wrote:
Nathaniel Echols wrote:
> The tricky part here is that we'd probably
> like to keep Python 2.4+ support too,
> 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.
OceanographerEmergency 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 receptionChris.Bar...@noaa.gov