[Python-3000] GUI -- an API, not a toolkit

[Giovanni Bajo]

Jim Jewett <jimjjewett at gmail.com> wrote:

> To just create a preference picker and an OK/Cancel dialog -- the
> mental overhead really shouldn't be much worse than using a single
> python module from the standard library.  (And yes, this rules out
> using pretty much any existing framework as the API.)


Does it?

>>> from qt import *
>>> app = QApplication([])
>>> QMessageBox.question(None, "Confirmation", "Are you sure you want to
exit?", QMessageBox.Yes, QMessageBox.No)
[ dialog popups ]
3
>>> QMessageBox.Yes, QMessageBox.No
(3, 4)

I don't agree with much of what you propose basically because I think it's
hopeless to create a wrapper API above all the toolkits. There are far too many
"details" which are different (just thinking of events, application event
loops, signals/slots, HW accelerated painting primitives, multithreading
dispatching). I dare anyone to develop such an API so that it's
production-ready (which is *not* a Yes/No dialog) within the Py3k time
constraint. I reckon that this is pratically unfeasable (and, say what, totally
useless).

My gut feeling is that we should either choose a good existing, tested binding
over a multi-years-developed-and-real-world-debugged toolkit, or we can just
drop the idea of distributing any GUI API with Python. Python's stdlib *is*
production ready, and shouldn't be cluttered with insufficient,
under-specified, limited APIs.

Giovanni Bajo