On 1/26/2011 11:35 AM, Robert Kern wrote:
On 1/26/11 10:00 AM, Emile van Sebille wrote:
On 1/25/2011 10:08 PM Octavian Rasnita said...
From: "Emile van Sebille" <em...@fenx.com>
Why is WxPython ineligible?
I think Terry's point was compatibility with python3 -- which wx
apparently isn't yet.
Emile
Well, I didn't know this, and it is a valid reason.
This means that it is true that there is no enough maintainance force to
keep WxPython updated.
Did I understand correctly?
Not at all -- wxPython is an active funded ongoing project. Review the
roadmap
at http://wiki.wxpython.org/TentativeRoadmap and particularly the final
paragraph on Python3.x support.
That's not Terry's point. The reasons he's referring to (and stated
previously) are as follows:
1. The license of wxWidgets and wxPython is not as permissive as
Python's. The Python developers, as a matter of policy, do not want to
include code into the standard library that is less permissive than the
current license.
2. The Python developers require someone to commit to maintaining
contributed code for a number of years. No one has done so. See reason #3.
3. The wxPython developers do not want wxPython in the standard library,
not least because they want to develop and release wxPython at a
different pace and release cycle than the standard library.
4. The Python developers have committed to maintaining backwards
compatibility in the standard library for a very long time. Even if they
included wxPython into the standard library, they would have to provide
a Tkinter module that works like the current one. I do not believe it is
feasible to write a Tkinter workalike that uses wxPython, so we would
still be relying on Tcl/Tk.
Yes, very well put.
Another point is non-gui baggage. In my opinion, and I suspect others,
this should be minimal to absent.
Tk itself is purely a gui package -- abstract widgits, geometry placers
to make them visible, and an event system to make them active. But it
does have the baggage of needing tcl included. About a decade ago, some
people had the idea of removing the tcl dependency, but nothing seems to
have come of that. For some people, the tcl baggage is reason enough to
be rid of tk.
Qt, in contrast to tk, is not a gui package, but an application
framework and library that includes QtGui as one of about 10 modules.
There is also, for instance QtSockets and QtScript (now included in
QtCore). Qt as a whole could not go into the stdlib.
From what I remember when I looked at the WxWidgets feature list some
years ago, WxWidgets does not come with a scripting language, but also
has more that strictly gui stuff. So I think it would also need to be
subsetted.
PyGui seems to be purely a gui package, but it appear to be aimed only
at 2.x with no interest in 3.x.
There is certainly enough maintenance force to keep wxPython updated and
ported to Python 3, but only *outside* of the standard library.
I got the opposite impression from the link above. As of last May, 3.x
support is deferred until a new C++ code generator is written, and that
is deferred until new features are added and released. So it seems the
project needs another person to either code the new code generator or
learn how to port Capi code (or both). Since there is no 2to3 for Capi
(as opposed to Python code), I do not even know is a single code base is
possible. I am sure that whoever works on a wxPython port could learn
from whoever did the numpy port.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
