py3k port
Amaury
Is there some work in progress to have wxPython working with python 3?
I started to hack in my working copy, and after a few hours I came
with a mostly working wxPython on top of CPython 3.2a0.
The demo now mostly works correctly!
The port was not easy, I fixed errors when I encountered them while
compiling and running. I did not use the 2to3 tool.
I had to use swig 2.0.0, with a slight change because
PyCObject_Import() was removed between 3.1 and 3.2 (the PyCapsule
object is now the official way to share C pointers)
The swig 2.0 patch: http://paste.pocoo.org/show/253494/
The wxPython patch: http://paste.pocoo.org/show/253496/
The patch is not perfect:
- I only tested on Windows
- I used svn trunk for both wxWidgets and wxPython, and they don't
exactly match. The patch contains some changes that really belong to a
2.9.1 -> 2.9.2 migration.
- Also, I did not try to keep backward compatibility: the new code
cannot run with a CPython 2.x
IMO the last point is the most important for any py3k support.
python 2.6 has some support for helping with 2->3 conversion (from
__future__ import print_function, unicode_literals), do we want to
support 2.5 as well?
What do you think?
Which priority do you give to a py3k port of wxPython?
Cheers,
--
Amaury
Andrea Gavana
I believe this is one of the best news I read about wxPython in the
last weeks. I don't personally care about Python 3, but if you're
about to make wxPython work against Python 3 you will have saved Robin
(and Kevin, and possibly other devs) a huge amount of work and
headaches. Plus, there have already been quite a few request for
support for Python 3 on this mailing list. I can only applaude your
efforts.
> Which priority do you give to a py3k port of wxPython?
That is a question I leave Robin to answer, but I believe he will be
quite happy. Obviously, maintaining 2 branches of wxPython (one for
Python 2 and the other for Python 3, if the code can not be shared
between them in some way) might be a bit complicated and
time-consuming, but again, I'll leave to Robin the answer.
As soon as we get an almost working copy of wxPython vs Python 3 in
SVN (or somewhere else), I'll move and port AGW to Python 3 too.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
==> Never *EVER* use RemovalGroup for your house removal. You'll
regret it forever.
http://thedoomedcity.blogspot.com/2010/03/removal-group-nightmare.html <==
Amaury Forgeot d'Arc
> The port was not easy,
Sorry, this is a typo. The port to py3k *is* easy and straightforward.
(which is a surprise in itself)
Of course, it's better to use a Unicode build of wxWidgets...
It is tedious sometimes, and some code looks really old (has_key,
types.ListType...)
The part I find difficult is the change in relative imports inside
packages: you cannot recursively import submodules.
--
Amaury Forgeot d'Arc
Robin Dunn
> Hi,
>
> Is there some work in progress to have wxPython working with python 3?
>
> I started to hack in my working copy, and after a few hours I came
> with a mostly working wxPython on top of CPython 3.2a0.
> The demo now mostly works correctly!
>
> The port was not easy, I fixed errors when I encountered them while
> compiling and running. I did not use the 2to3 tool.
> I had to use swig 2.0.0, with a slight change because
> PyCObject_Import() was removed between 3.1 and 3.2 (the PyCapsule
> object is now the official way to share C pointers)
>
> The swig 2.0 patch: http://paste.pocoo.org/show/253494/
> The wxPython patch: http://paste.pocoo.org/show/253496/
Many Thanks!
I'll try to take a closer look at these soon.
>
> The patch is not perfect:
> - I only tested on Windows
> - I used svn trunk for both wxWidgets and wxPython, and they don't
> exactly match. The patch contains some changes that really belong to a
> 2.9.1 -> 2.9.2 migration.
> - Also, I did not try to keep backward compatibility: the new code
> cannot run with a CPython 2.x
>
> IMO the last point is the most important for any py3k support.
> python 2.6 has some support for helping with 2->3 conversion (from
> __future__ import print_function, unicode_literals), do we want to
> support 2.5 as well?
I think it will be important to be able to support both 2.x and 3.x from
the same source tree, at least for a few wxPython releases. wxPython is
huge and so doubling the amount of maintenance and enhancement work by
forking the source tree really isn't acceptable. OTOH, I could go along
with dropping support for 2.5 if that's what it takes to be able to keep
a single source tree.
--
Robin Dunn
Software Craftsman
http://wxPython.org
Christopher Barker
Robin Dunn wrote:
> I think it will be important to be able to support both 2.x and 3.x from
> the same source tree, at least for a few wxPython releases.
FWIW, numpy has been able to do that.
> OTOH, I could go along
> with dropping support for 2.5 if that's what it takes to be able to keep
> a single source tree.
I don't know what versions numpy is supporting, as I'm on 2.6 now, but
it may be worth a look to see what they've done.
-CHB
--
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
Amaury Forgeot d'Arc
I started a Mercurial patch queue to follow my changes to wxPython:
https://bitbucket.org/amauryfa/wxpython-py3k
A patch queue has the advantage that the (large) changes can be split
into several
manageable patches, each one can be reviewed, discussed and applied separately.
At the moment, I work by running the Demo, and fix errors when I encounter them.
The wiki page:
https://bitbucket.org/amauryfa/wxpython-py3k/wiki/Home
already presents some of these patches that are easy to understand and
safe to use for any Python version (since 2.2 at least),
They mostly remove old syntax than most python programmers don't use anymore...
Robin, feel free to pick and apply some of them as you wish, even partially.
Mercurial Patch Queues will make it easy for me to track the changes
you make to the trunk version of wxPython,
I'll update or remove the patches when necessary.
Other patches are less straightforward, some require at least some
basic test, and other probably need more work.
The advantage of the Patch Queue is that a discussion can take place
while not stopping other topics.
All patches are necessary to make wxPython work with python3.x,
but this does not mean that all changes should be done the same day!
Robin Dunn
> Hello,
>
> I started a Mercurial patch queue to follow my changes to wxPython:
> https://bitbucket.org/amauryfa/wxpython-py3k
Thanks, this will be really helpful. I'll start working through those
after I get a 2.9.1 release done. I'm feeling like that is overdue and
so I'm putting my priorities there for now.
Are you pulling from SVN or from my "workspace snapshot" repository at
http://hg.wxpython.org/hg/wxPy-trunk/? At this point it probably
doesn't matter very much either way, I'm just curious.
Amaury Forgeot d'Arc
2010/8/31 Robin Dunn <ro...@alldunn.com>:
> Are you pulling from SVN or from my "workspace snapshot" repository at
> http://hg.wxpython.org/hg/wxPy-trunk/? At this point it probably doesn't
> matter very much either way, I'm just curious.
I indeed use this snapshot with Mercurial.
I think it's the best approach if I want to use the "Mercurial Queues"
extension.
I regularly "rebase" the patches when you push changes to the repository,
so they stay up to date.
This is the first time I use Mercurial; I find the patch queue very well suited
for this kind of task, because it can make large changes understandable and
manageable, and does not require any permission to write to the base repository.
Robin Dunn
> Hi
>
> 2010/8/31 Robin Dunn<ro...@alldunn.com>:
>> Are you pulling from SVN or from my "workspace snapshot" repository at
>> http://hg.wxpython.org/hg/wxPy-trunk/? At this point it probably doesn't
>> matter very much either way, I'm just curious.
>
> I indeed use this snapshot with Mercurial.
> I think it's the best approach if I want to use the "Mercurial Queues"
> extension.
> I regularly "rebase" the patches when you push changes to the repository,
> so they stay up to date.
For the record, it can be done when the source is SVN too. Basically
you have a SVN checkout that is also a HG repository. You clone that to
another repository where you do your work. When there are updates in
the SVN repository you do an update, and commit the changes to HG too.
Then in your workspace you pull changes from the SVN/HG repository and
then rebase your patches if needed.
>
> This is the first time I use Mercurial; I find the patch queue very well suited
> for this kind of task,
Yep, I like MQs too. I've started using it whenever I work with 3rd
party code where I want to make changes. I should probably start using
it with my wx workspaces too, so I can more easily work on multiple
changes at once and then untangle them when it's time to commit the
changes to SVN.