python 3

[Stephen Gava]

Hi there,

I'm just looking back at wxpython again after working on 3 projects in a
row that used the 3.x python series. When it came to gui toolkits
wxpython of course fell at the first hurdle, with no support for pythion
3, so 2 of the projects ended up using pyqt and one used tkinter.

Anyway, with python 3.2 now offering significant improvements over the
2.x series, and no more backporting of new features from 3 to 2, this
problem is only going to arise more and more often, so I just popped in
to ask if there's any update on python 3 support for wxpython?

The last thread I could find on here that even touched on this looks
like it's from several months ago.

Fwiw wxpython is one of the front runners in the python.org poll on what
library people want to see ported to python 3. ;)

Anyway, cheers for all the fantastic work on wxpython,
Stephen.

[carl gonzalve]

I pretty much succeeded in port a majority of wxPython, I'd say at least 85%. But I'm currently at IT A school at Corry station Naval base at Pensacola, and my desktop is at home, not to mention I have no net access at the barracks, so there's not much I can do right now. I am planning to have my desktop shipped over though, should take a week or so. Once that happens I could send you a test version of my port, assuming you're comfortable with 64-bit binaries. By the way, do you know anyone selling a decent laptop with at least a Core 2 duo, 256Mb VRAM and 4Gb RAM?

--
To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-dev?hl=en

[Amaury Forgeot d'Arc]

Hi,

2011/9/15 carl gonzalve <game...@gmail.com>

I pretty much succeeded in port a majority of wxPython, I'd say at least 85%. But I'm currently at IT A school at Corry station Naval base at Pensacola, and my desktop is at home, not to mention I have no net access at the barracks, so there's not much I can do right now. I am planning to have my desktop shipped over though, should take a week or so. Once that happens I could send you a test version of my port, assuming you're comfortable with 64-bit binaries.

Wouldn't you share the source code instead?

Some months ago I also started a py3k port,

it's already available as a bunch of patches (A mercurial patch queue):

https://bitbucket.org/amauryfa/wxpython-py3k

There is still some work to do, must the demo is mostly working.

I tries to organize the patches in pieces with similar changes,

like: "except ... as", removal of long, etc etc.

Some of these patches are compatible with 2.6 at least, so they could be reviewed and apply now.

--
Amaury Forgeot d'Arc

[elguavas]

Thanks Carl and Amaury for your replies and interesting work on this.

I think wxpython will only be seriously considered by many for python
3 projects once there is a core wxpython release with python 3
support, at least a development release. Is there any possibility of
the work either of you has done being folded into core wxpython so
that an official development release can be made?

Cheers,
Stephen.

[Christoph Gohlke]

Makes me wonder how many private ports of wx are out there. I too got wxPython-2.8.12.dev running on win-amd64-py3.2 a while ago to test matplotlib-py3. Most of wxPython's demos worked well. I never finished it though. Especially agw was tedious...

Christoph

[Amaury Forgeot d'Arc]

2011/9/15 Christoph Gohlke <cjgo...@gmail.com>

I too got wxPython-2.8.12.dev running on win-amd64-py3.2 a while ago to test matplotlib-py3

Please share your code, so that we can consolidate a unique version

which will have more chances to make its way to the official release.

[Andrea Gavana]

As far as I can see, in order to get AGW (and indeed the entire wx.lib) to run on Python 3 you only need to feed it to 2to3 and test the automagically converted code. I don't foresee a huge or tedious job (I already do it automatically while building the AGW docs on my website). But then, I never actually tested the resulting code so I may well be mistaken.

Andrea.

On Sep 15, 2011 9:48 AM, "Christoph Gohlke" <cjgo...@gmail.com> wrote:
> On 9/14/2011 5:10 PM, Amaury Forgeot d'Arc wrote:
>> Hi,
>>

>> 2011/9/15 carl gonzalve <game...@gmail.com <mailto:game...@gmail.com>>

> --
> To unsubscribe, send email to wxPython-dev...@googlegroups.com
> or visit http://groups.google.com/group/wxPython-dev?hl=en

[Amaury Forgeot d'Arc]

2011/9/15 Andrea Gavana <andrea...@gmail.com>

As far as I can see, in order to get AGW (and indeed the entire wx.lib) to run on Python 3 you only need to feed it to 2to3 and test the automagically converted code. I don't foresee a huge or tedious job (I already do it automatically while building the AGW docs on my website). But then, I never actually tested the resulting code so I may well be mistaken.

2to3 won't handle the bytes/string mismatches.

And it cannot convert the SWIG modules...

[Andrea Gavana]

There is no SWIG module in AGW, and none that I know of in the entire wx.lib.

Bytes/string mismatch might be a very limited issue as well for these libraries.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

>>> import PyQt4.QtGui

Traceback (most recent call last):

  File "<interactive input>", line 1, in <module>

ImportError: No module named PyQt4.QtGui

>>>

>>> import pygtk

Traceback (most recent call last):

  File "<interactive input>", line 1, in <module>

ImportError: No module named pygtk

>>> 

>>> import wx

>>>

>>>

[Kevin Ollivier]

Hi Amaury,

As Robin has said in the past, Project Phoenix is the way to get Python 3 support that he will invest his time in, and I doubt that has changed. I've done some work on it myself, and given the ease of adding new classes to it, and how much smaller and more efficient the resulting bindings are when using the SIP bindings generator, I think it's hard to imagine that wxPython will still be using SWIG bindings this time next year. So doing all the work to get Python 3 support for SWIG, then ditching SWIG a few months later in favor of something else, doesn't seem to me the best route to take.

It may sound like one of those "really big overhaul" projects that are just too much work and never happen, but as an example, here is what the wxWindow bindings look like in the new system:

http://trac.wxwidgets.org/browser/wxPython/Phoenix/trunk/etg/window.py

The output of the above script is a complete set of wxWindow bindings, with properties, overridable virtuals, AFAIK Python 3 support (haven't tested but SIP has Py 3 support), etc. that passes the wxPython wxWindow test suite (aside from a couple missing things like PyAssertionError). And it's even quite likely lines 164-222 could be removed and replaced with a tools.addGetterSetterProps(module) call. Plus, so long as any wxWindow interface changes are documented, they will instantly, and without extra effort, be propagated to the wxPython bindings. Compare that with the 2500+ line SWIG _window.i file which must be manually changed each time a method is added / removed / changed. I've been adding classes to the new bindings at the average rate of about 1-2 hours per class. I've also done some work on a wx.dataview module, which I hope to land soon, and it was pretty easy to get going. 

Compare that with the current bindings, and I think you'll see this not only solves our Python 3 problem, but also a lot of our other existing problems as well. As an example, if someone were to work on: 

http://trac.wxwidgets.org/browser/wxPython/Phoenix/trunk/etgtools/sphinx_generator.py

using 

http://trac.wxwidgets.org/browser/wxPython/Phoenix/trunk/etgtools/sip_generator.py

as a model, with a few hundred lines of code or so, we could also be generating Sphinx docs, which are as complete as the wx docs, and from there we can tweak them for Python-specific stuff as needed. (Amazingly, a similar amount of work could probably get us complete Perl, C, Lua, etc. bindings too.)

These things take so long because Robin's a pretty busy man, but I can say with certainty that Project Phoenix is the best way he can spend what time he does have to help out the wxPython project. At this speed, I can say this project will almost certainly have fairly complete bindings ready for testing in months, and that's assuming the current contributors don't have a lot of time to devote to it. In man-hours, I think we're looking at a couple weeks of work.

Regards,

Kevin

--
Amaury Forgeot d'Arc

--

[Robin Dunn]

On 9/15/11 12:54 AM, Amaury Forgeot d'Arc wrote:
> 2011/9/15 Christoph Gohlke <cjgo...@gmail.com <mailto:cjgo...@gmail.com>>

>
> I too got wxPython-2.8.12.dev running on win-amd64-py3.2 a while ago
> to test matplotlib-py3
>
>
> Please share your code, so that we can consolidate a unique version
> which will have more chances to make its way to the official release.

My plan is to do the Python3 port as part of the Phoenix Project so it
does not have to be done twice. Since a lot of things will be changing
in the core extension modules in not totally compatible ways it will
also be a good time to change things in the python modules too. If
things need to break a little to work with Phoenix anyway then I think
that breaking them a little more to work with Python3 at the same time
will help minimize the pain. And hopefully we can end up with one set
of code supporting both 2.7 and 3.2 (with 2to3 if needed) for a release
or two.

I know this just sounds like the same old tune that I've been singing
before, but the good news is that Phoenix is moving forward again.
There has been a lot of progress in the last few weeks,
(http://trac.wxwidgets.org/log/wxPython/Phoenix/trunk) and the future is
looking shiny (smaller, faster, *and* stronger.)

--
Robin Dunn
Software Craftsman
http://wxPython.org

[Amaury Forgeot d'Arc]

2011/9/15 Robin Dunn <ro...@alldunn.com>

I know this just sounds like the same old tune that I've been singing before, but the good news is that Phoenix is moving forward again. There has been a lot of progress in the last few weeks, (http://trac.wxwidgets.org/log/wxPython/Phoenix/trunk) and the future is looking shiny (smaller, faster, *and* stronger.)

These are *excellent* news!

But if you want to spend some time before the Phoenix lands, please have a look at the patches in

https://bitbucket.org/amauryfa/wxpython-py3k/src

Start with all the patches that start with "modern-": they remove old-fashion constructs that are not supported by python 3; the replacements are compatible with Python 2.4 at least, and look better anyway.

[elguavas]

On Sep 16, 2:21 am, Robin Dunn <ro...@alldunn.com> wrote:
> My plan is to do the Python3 port as part of the Phoenix Project so it

>[...]

> looking shiny (smaller, faster, *and* stronger.)

Ok, thanks for the update, and of course the work, Robin, I look
forward
to some development releases that I can do some testing on in the not
too
distant future.

Best wishes,
Stephen.

[jmfauth]

On 15 sep, 11:01, Andrea Gavana <andrea.gav...@gmail.com> wrote:
>
> Bytes/string mismatch might be a very limited issue as well for these
> libraries.
>

The bytes/str (*in three letters*) mismatch is already
existing in wxPy2.9. Not in the that form, in the form
str/unicode.

jmf

[jmfauth]

On 15 sep, 18:21, Robin Dunn <ro...@alldunn.com> wrote:
> ... And hopefully we can end up with one set

> of code supporting both 2.7 and 3.2 (with 2to3 if needed) for a release
> or two.

This will not work and it can not safely work. It may
only work in the direction Python 3 -> Python 2, with
the 3to2 tool.

By putting all this en/de-coding machinery in the toolkit,
you are "only" duplicating what Python is already
doing. The automatic coercion ascii/str -> ascii/unicode,
In a litte bit more sophisticated way.

A more serious concern. You are killing the performances of
your toolkit in a pure Python3/unicode as str mode.

The worth of all possible designs. A design which does not
solve the basic problem: non Python 2 compliant unicode code
can not be automagically be ported to Python3.

PySide is doing correctly. Populating a text widget with
this "abc需" does not work. Populating with u"abc需"
works.
Populating a widget with this "abc" works and does u"abc"

Simple, straightforward, logical and Python (2) compliant!

PyQt4 for Python3 is woking in the same way. It is simply
less visible.

jmf

[jmfauth]

It seems Google has changed again.

If you can not read this "abc需" in my previous
message, it is in a Unicode nomenclature:

LATIN SMALL LETTER A
LATIN SMALL LETTER B
LATIN SMALL LETTER C
LATIN SMALL LETTER E WITH ACUTE
LATIN SMALL LIGATURE OE
EURO SIGN

jmf