WxPython versus Tkinter.

[rantingrick]

On Jan 26, 10:35 am, Robert Kern <robert.k... at gmail.com> wrote:
> On 1/26/11 10:00 AM, Emile van Sebille wrote:

> 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.

This is actually a weak argument and i'll explain why. GUI libraries
are very complicated and time consuming projects. Just think of all
the work involved just to get a library working on one platform...
much less THREE or more platforms! And while i am a huge believer in
100% open source software you've got to understand why most libraries
are restrictive for commercial usage or worse. Yes TclTk IS fully
opensource and i applaud them for it! However like the old adage say:
"You get what you pay for".

> 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.

I have already shown why this does not matter. The current wxPython
API is NOT good for Python. We DO NOT want segfaults and "C++ looking"
code written by the users of a Python stdlib module. Robin has stated
that there exists room for an abstraction layer on top of wxPython and
he is correct. He has also stated that he wants to keep "his wxPython"
as close to WxWidgets as possible. So be it! We will never want to
include wxPython "proper" in the stdlib anyway because it is SO
unpythonic!! No. All we have to do is create an abstraction API that
calls wxPython until we can create OUR OWN wxPython from WxWidgets.
Call it Wxpy if you like.

> 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.

Fine support Tkinter until Python4000 i don't care. But we must move
forward. We must accept that Tkinter is already legacy and there is no
moving forward now. We will support Tkinter for backwards
compadibility however we will start to integrate a truly Pythonic
WxPython abstraction API and include just the API module in the
stdlib. Then we don't have to maintain a huge library, just a small
module with a wxPython 3rd party dependency. Then at some point in the
future when the stdlib is ripe, we can THEN include some form of
wxWidgets, and dump Tkinter forever. At least then we would be moving
towards something. Currently we are stagnate.

>
> There is certainly enough maintenance force to keep wxPython updated and ported
> to Python 3, but only *outside* of the standard library.

So let wxPython due what wxPython does best. We will use them as long
as we need until we can create a stdlib compliant wxPython ourselves.
They would be fools not to work with us! Because eventually when no
3rd party download is needed, all their work would go into the bit
bucket. I doubt Robin is that foolish. He seems like a smart fellow to
me -- even though he refuses to comply with PEP8 :)



SUMMARY: We create an abstraction API atop "Robin's WxPython". We
include only the API in the stdlib at this time and we keep Tkinter in
maintenance. Then over the next few years we start a fresh wxPython
project that will be acceptable for the stdlib. Something that we can
plug our API into.  We steal as much from Robin as we can (or get him
to cooperate). Then when the time is right, we dump Tkinter and
integrate the new Wxpy module into the stdlib. Then we will be back on
track.