WxPython versus Tkinter.

[Terry Reedy]

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" <emile at 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