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 -- http://mail.python.org/mailman/listinfo/python-list
