On Jun 10, 3:06 pm, Stephen Hansen <me+list/pyt...@ixokai.io> wrote:
> And actually: things do go to the stdlib to die. Its actually a very apt > description of exactly how things work. Once a module gets added to the > stdlib, its sort of dead. Static. It might change, in this > excruciatingly slow pace, with strict rules for compatibility over > consistency. It takes years and years before you can fix a design error > -- you have to wait until the next major release to put a new option in, > do some deprecation (be it pending or regular, it depends), and then a > whole new major release before you can finally be fixed. Actually this is a very accurate description of the process, and i agree. And some modules will do ok in this environment because by nature they are static. However, i think you'll also agree that GUI has been (and continues to be) an ever evolving beast. With many, many, library's to choose from and nobody can agree that *this* or *that* GUI library is better. As is evidenced by the lack of development for Tkinter. But with Tkinter there is a larger problem, TclTk! Even Tk is not a full featured GUI library, much is to be desired. So with all that in mind i ask you again... Since GUI's are not as easy to maintain due their inherent fluidity (unlike other "more static" modules)... and since the process by which they are maintained is excruciatingly slow... why then include a GUI at all? Free up pydev and send Tkinter to the bitbucket! But if you *do* decide to include a GUI, should it not at *least* be based on the native widgets like PyGUI? I think going native is going to be the only answer here. When in Rome... -- http://mail.python.org/mailman/listinfo/python-list