On Jan 26, 10:35 am, Robert Kern <robert.k...@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. -- http://mail.python.org/mailman/listinfo/python-list
