On 1/27/11 1:11 PM, rantingrick wrote:
Actually we don't want "Robins wxPython" in the stdlib "as is" anyway. What we DO want is an abstraction API for the short term that plugs into Robin's wx. Then over the long term we will either convince him to create a better API OR just create our own wxPython directly from WxWidgets and mold it into the stdlib. So hinging on the argument of what one*single* man thinks is a non-starter.
I saw this comment elsewhere in the thread, and I'm a bit confused. As I understand it, you want to layer a Tkinter-style abstraction API over wxPython? You had mentioned that you want to include something like Tkinter's grid/pack/place management API's, its event-handling mechanism, its use of tags, and a few other things?
I'd like to suggest that these things are already in the stdlib, in the form of Tkinter itself. And at least some thing these things are tightly bound to Tkinter's inclusion of the Tcl interpreter. For instance, Tcl has a powerful and flexible event loop mechanism. Does wxWidgets have something similar? And are Tkinter's grid/pack/place geometry managers (which are defined at the C level) compatible with wx sizers, which are also defined at the lower C++ level?
While this thread has taken many twists and turns, it nonetheless seems to me that the proposal being offered is to layer a Tkinter-style API over a Tkinter-scale subset of wxPython's widgets (listbox, button, menu, etc.). After all that work, what would really be gained? We'd have the same small core of widgets, with an arguably less stable base (since wxPython seems to have problems with segfaults on Linux).
It is not persuasive to say that Tkinter is "legacy" while wxPython is "the future." Both Tk and wxWidgets date to the early 1990s. Tk did stagnate for a number of years, but its development in the past few years has been reinvigorated by the ttk themed widgets, in addition to various extension packages that use Tk's C API, and it is now a peer to wxWidgets in its GUI capabilties. I can't speak to Tkinter's performance relative to wxPython and the Tcl interpreter, but any performance gains that are achieved by wxPython's underlying C++ library may be obviated by lesser stability.
After all the back-and-forth, I am simply not persuaded, especially since the proposal being offered is not to replace Tkinter with wxPython in the stdlib, but to instead replace Tkinter with a yet-to-be-designed wxTkinter amalgamation (a Tkinter body on a wxPython chassis).
--Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
