py3k port

wxPython Dev
1

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/

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

2

Hi,

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/

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?

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.
The Doomed City: Removal Group: the nightmare <==

···

On 23 August 2010 14:19, Amaury wrote:

3

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.

···

2010/8/23 Amaury <amauryfa@gmail.com> wrote:

The port was not easy,

--
Amaury Forgeot d'Arc

4

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.

···

On 8/23/10 6:19 AM, Amaury wrote:

--
Robin Dunn
Software Craftsman

5

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

Chris.Barker@noaa.gov

6

Hello,

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!

···

--
Amaury Forgeot d'Arc

7

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.

···

On 8/30/10 5:08 AM, Amaury Forgeot d'Arc wrote:

Hello,

I started a Mercurial patch queue to follow my changes to wxPython:
https://bitbucket.org/amauryfa/wxpython-py3k

--
Robin Dunn
Software Craftsman

8

Hi

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.

···

2010/8/31 Robin Dunn <robin@alldunn.com>:

--
Amaury Forgeot d'Arc

9

Hi

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.

···

On 8/31/10 12:55 PM, Amaury Forgeot d'Arc wrote:

2010/8/31 Robin Dunn<robin@alldunn.com>:

--
Robin Dunn
Software Craftsman