anygui,anydb, any opinions?

[Shane Hathaway]

rzed wrote:
> 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?

See "The Law of Leaky Abstractions" by Joel Spolsky.

http://www.joelonsoftware.com/articles/LeakyAbstractions.html

As he says, "All non-trivial abstractions, to some degree, are leaky."
GUI abstractions tend to leak badly.  As I write this email in
Thunderbird, my initial impression is that most of the controls on the
screen are pretty standard and could be done with virtually any
toolkit... or are they?  Looking again, the "from" field has both a
place for me to type and some grayed out text that reminds me I'm
posting from a different account; the "to", "cc", and "newsgroup" fields
are not quite combo boxes; the toolbar has pulldown buttons.

So it turns out that Thunderbird is actually tied to a particular
toolkit, and for good reason: GUI development has not stagnated; toolkit
developers continue to invent new, interesting widgets and variations,
leading to better UIs.  Application developers want to take advantage of
those innovations.

Even anydbm is a pretty leaky abstraction.  I recently tested the
behavior of 5 Python dbm implementations when they run out of disk
space.  Most left the database in an inconsistent state, some swallowed
the exception, some segfaulted, and one deadlocked.  If I'm going to
rely on a dbm module, I really need to know what it's going to do when
it hits an exceptional condition.  Thus anydbm seemed like a bad choice.

Shane