Since I am deeply lacking in attention span, a project has occurred to me. Well, it's not actually that scattered of me, but it's not really very incremental; a need to start new projects.

Anyway, the project is an extraction and formalization of some inner parts of SQLObject, mostly the non-ORM parts. This would be:

• The basics of SQLBuilder, but based on the paramstyles branch. SQLBuilder is a domain-specific language formed in Python syntax for expressing SQL queries.
• Some database coercions. SQLObject currently doesn't use native database parameters, instead constructing complete SQL. This is a problem. However, while databases have some differences in SQL literals, they also have differences on the driver level, so using parameters does not mean that you can forget about database-specific hacks. I think this is where Oleg's work on that paramstyles branch gotten hung up. You just can't trust databases.
• Some higher-level database portability abstractions. These are scattered through SQLObject right now. I don't think when I started SQLObject that I really knew what kind of abstractions were necessary; it's really not obvious. But now I do. This involves things like portable descriptions of database column types.
• Some higher level routines, like getting information on what databases exist, what tables, what kind of columns those tables have, etc.
• The database connection URI parsing, using entry points to allow databases to register themselves.
• Maybe some other little things, like connection pooling, and unifying the database exception hierarchy across backends.

I feel confident all these things can be done; SQLObject does them all (but in a very ad hoc fashion at the moment). And that this will be generally useful (assuming someone chooses to use it). I'd rather SQLObject be built on some ORM-neutral layer, where you can move down to that layer when SQLObject doesn't fit your problem; as opposed to now, where you kind of have to work around SQLObject. (Actually, it's only the caching you have to work around, and this doesn't really address that, but at least it will separate concerns and I hope make SQLObject a bit more nimble.)

This would not be just a spec, like the DB API, but an actual frontend module with lower-level database backend plugins.

Anyway, it's just an idea for now, but I thought I'd throw it out there.