anygui,anydb, any opinions?

[rzed]

Periodically, we see questions about which gui package is best, or 
which database package to use. These questions typically trigger 
some exchanges of opinion, though of course this no one best 
answer, and eventually things quiet down until the next round.

But it seems to me that what seldom gets asked is: why is it 
Python's concern which package to use for those purposes? It seems 
to me that a proper approach from the viewpoint of the language 
itself is to provide an interface, and for the package developers 
to provide an implementation of that interface. A Python program 
would thus address its api only, leaving it up to the package to 
interpret that properly. In the ideal world, this would mean that 
any Python program could swap the gui package (or the db package) 
without changing the logic of the program. Python-the-language 
(rather than Python-the-package) would theoretically be a more 
compact download, and the hooked-in parts could be installed 
separately.

Anygui and anydb have been attempts to reach the ideal interface 
(and there are others, I think), but each has its problems and 
neither is supported or developed as fully as the idealized 
interface would require. I don't see much evidence that the various 
packages are designed to conform to those designs (and I don't 
contend that they should be required to until and unless the 
generic interfaces are in a well-developed state). But the result 
of all this is that there continues to be confusion to newbies and 
even veterans who are new to a given area or platform. Shouldn't it 
be a priority to eliminate the source of that confusion?

Now, on the grounds that practicality beats purity, it's certainly 
reasonable to argue that the current system works better. If we 
could just jump into a state where there was a perfectly-
functioning anydb and anygui, then we'd already have been there, 
but we can't and so we won't try to go in that direction at all. 
Python-the-package marches on; it can't wait for some ideal to 
coalesce before it advances. It's hard to argue too strongly 
against that view.

Then, too, it's hard to see how an anygui or (more especially, I 
think) an anydb could possibly work in the real world. The various 
approaches to windowing and databases are too different for a 
single interface to encompass them all. Some capabilities would be 
unforeseen or ignored in any such interface. That argument carries 
a lot of force. Certainly it is true that adding parameters to a 
function call to accommodate some new feature gets real old real 
soon. But while it is a strong practical argument, it is not one 
that truly wins in the long run, I think. It is an argument in 
favor of changing the way arguments are passed, so that it becomes 
possible to handle the various pieces of information the lower-
level package needs. The interface should be agnostic as much as 
possible. The package should be able to get the information it 
needs from what is passed by the api. Both of these things must be 
true.

Back when I was programming in DEC C, I saw how their 
implementation of functions like printf departed from the C 
standard by adding optional keyword parameters. Using those 
parameters, DEC's more-sophisticated filesystem could be used 
productively without going deeply into the filesystem's api. 

Of course, a program written that way wouldn't work if transferred 
unchanged to another system, but it *could* have worked if the 
other system could also either handle the keywords (or some of 
them) or ignore them. The results may not have been exactly as 
desired, but there would have been results. Similarly, an elaborate 
call that allows access to a sophisticated gui should also produce 
results if the gui is simpler. Supposing that a given parameter 
required by the second system has not been included in the first 
place, it should be possible to add that parameter without 
affecting the first system one bit. The first one would still not 
be looking for the parameter, while the second would now find it.

That's all I'm talking about here. To be able to write a Python 
application that can ultimately be displayed using wxWidgets or Qt 
or Tkinter or Curses. Then, without having to do more than to 
change which interface package is imported, to expect to see the 
result displayed. To have it just happen, and to have expectations 
when using Python that it *will* just happen that way.

So what do you think? What's wrong with the picture? Why isn't 
there a greater priority to work in this direction?

-- 
rzed