GUIs - A Modest Proposal
in [Python]
|
From: rantingrick on 10 Jun 2010 15:36 On Jun 10, 1:56 pm, Stephen Hansen <me+list/pyt...(a)ixokai.io> wrote: > So... uh, why again are we including it? Those people who need it, have > ready access. But what if Mark decided one day he no longer wants to support Python or Win32? How many years will it be before someone writes another? > Why not include wxPython <snip> > Why not include PyQT? <snip> Both are not-starters for many reasons already discussed in this thread. Maybe wax would have a chance if we made it more Pythonic as Greg pointed out. All others are a non-starter due to the zen (import this). > Again: it has nothing at all to do with people not liking GUI's or > thinking GUI's are going the way of the dodo. It has to do with people's > ideas of what should or should not go in the standard library. Generally > speaking? Stuff that everyone or most people can make ready use of... > and while yes, doing GUI development is very, very common -- "GUI > development" is not a single monolithic thing. Different people have > some *very* different needs for what they get out of their GUI development. And again the opponents miss the whole point. It's not about including a GUI that would make everyone happy. Its about including a GUI that is complimentary to Python's stated goals. Not for you, Not for me, Not for the x&lee... remember? ;-) > The reason we do not embed any 'better' GUI then Tkinter into the > stdlib? There's several tools available for the job: and there is no > clear indication or agreement that one is better or more qualified for > inclusion over the others. At least, IMHO. I do not speak for python-dev. So i guess then the question becomes... Why keep supporting it? It's time to say Bye-Bye to Tkinter. > There is clearly no "our" Python. i beg to differ my friend. > PyGUI is indeed a solid project, and perhaps-- eventually-- a contender > for replacing Tkinter, once it works the kinks out and matures. Maybe it > is almost mature enough now? Maybe it needs more help? If so-- your time > would be better spent downloading it, using it, and offering some > patches I am in the process of that right now! > Things don't go into the stdlib to mature. Agreed! And likewise "things" should not be left to clutter the stdlib needlessly only to wither and die a slow death just because no one has the vision (or the motivation) to fix them or remove them for the sake of Python's evolution.
From: Ethan Furman on 10 Jun 2010 16:14 Stephen Hansen wrote: > Another thing you can look at is QT/PyQT. If you're doing GPL'd > software, that might be a very good solution for you-- you can design > your whole app in the beautiful QTDesigner, and the .ui files can be > used in any language with a QT binding, PyQT included. But you gotta be > GPL'd to use Python. (Although QT is now LGPL, the PyQT bindings > continue the GPL/commercial split... and PySide isn't cross platform yet) Correction: But you gotta be GPL'd to use PyQT. Python doesn't care.
From: Stephen Hansen on 10 Jun 2010 16:06 On 6/10/10 12:36 PM, rantingrick wrote: > On Jun 10, 1:56 pm, Stephen Hansen <me+list/pyt...(a)ixokai.io> wrote: > >> So... uh, why again are we including it? Those people who need it, have >> ready access. > > But what if Mark decided one day he no longer wants to support Python > or Win32? How many years will it be before someone writes another? Very few, I suspect. There's very little you can do with pywin32 that you can't do with ctypes. PyWin32 served a pretty important role once upon a time when you might need to do certain low level win32 api's. These days, I just use ctypes. The primary purpose I use pywin32 for is documentation or to see how someone solved a problem *using* pywin32: I then rewrite it in ctypes. But, should some mythical occasion come and Mark decides not to support either anymore-- we'll be in the exact same position now as to then. Someone'll need to step up and maintain it. Something being in the stdlib doesn't mean its maintained: in fact, that's a very dangerous part about inclusion. There's a number of modules already in the stdlib which don't have anyone responsible for them, and its really, really hard to get bugfixes into them unless someone is very interested or its a serious bug. >> Why not include wxPython <snip> >> Why not include PyQT? <snip> > > Both are not-starters for many reasons already discussed in this > thread. Maybe wax would have a chance if we made it more Pythonic as > Greg pointed out. All others are a non-starter due to the zen (import > this). I like how you left out all my talk of dependencies. That's very important when you're talking about stdlib inclusion: wax depends on wxPython. Thus, non-includable, as wxPython is non-includable and so something dependent upon it is as well. > >> Again: it has nothing at all to do with people not liking GUI's or >> thinking GUI's are going the way of the dodo. It has to do with people's >> ideas of what should or should not go in the standard library. Generally >> speaking? Stuff that everyone or most people can make ready use of... >> and while yes, doing GUI development is very, very common -- "GUI >> development" is not a single monolithic thing. Different people have >> some *very* different needs for what they get out of their GUI development. > > And again the opponents miss the whole point. It's not about including > a GUI that would make everyone happy. Its about including a GUI that > is complimentary to Python's stated goals. Not for you, Not for me, > Not for the x&lee... remember? ;-) You make a statement about GUI's not going away, and how all of us GUI haters need to get on board-- then leave that statement out-- and say I miss the whole point when I say its got nothing to do with that. Okay, well. You want to include a GUI that's not for, well, anyone. But ideologically sound. Okay, well. Tkinter is complimentary to Python's stated goals. The method by which that compliment happens (with TCL in the middle) is a bit strange, and the syntax leaves something to be desired-- but its really not that bad, and there's other modules in the stdlib more unpythonic. Its easy to use, reasonably powerful, and if you use the new themed widgets (which isn't terribly hard to do), not even too ugly. >> The reason we do not embed any 'better' GUI then Tkinter into the >> stdlib? There's several tools available for the job: and there is no >> clear indication or agreement that one is better or more qualified for >> inclusion over the others. At least, IMHO. I do not speak for python-dev. > > So i guess then the question becomes... Why keep supporting it? It's > time to say Bye-Bye to Tkinter. Because there is no clearly superior alternative available. Didn't I just say that? I swear I did. Until there is, Tkinter is "good enough". >> Things don't go into the stdlib to mature. > > Agreed! And likewise "things" should not be left to clutter the stdlib > needlessly only to wither and die a slow death just because no one has > the vision (or the motivation) to fix them or remove them for the sake > of Python's evolution. Tkinter is maintained, works, and is updated continually to make available the latest things that become available in Tk. 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. -- Stephen Hansen ... me+list/python (AT) ixokai (DOT) io
From: Stephen Hansen on 10 Jun 2010 16:11 On 6/10/10 1:14 PM, Ethan Furman wrote: > Stephen Hansen wrote: >> Another thing you can look at is QT/PyQT. If you're doing GPL'd >> software, that might be a very good solution for you-- you can design >> your whole app in the beautiful QTDesigner, and the .ui files can be >> used in any language with a QT binding, PyQT included. But you gotta be >> GPL'd to use Python. (Although QT is now LGPL, the PyQT bindings >> continue the GPL/commercial split... and PySide isn't cross platform yet) > > Correction: But you gotta be GPL'd to use PyQT. Python doesn't care. Er, yes. I meant Python's PyQT bindings, without a commercial license. Oops! Python's all <3 about any sort of use anyone wants to use it for. -- Stephen Hansen ... me+list/python (AT) ixokai (DOT) io
From: rantingrick on 10 Jun 2010 17:20
On Jun 10, 3:06 pm, Stephen Hansen <me+list/pyt...(a)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... |