在webpy的整个framework中，我觉得最不合理也最失败的就属这个web.database的封装了。

就我本人的理解，webpy对database的封装不说应该做到Django或者SQLAlchemy的水平，至少应该保持接口一致吧，但我们的webpy是什么样子呢？举个简单的例子，初始化一个database：

对于sqlite是这样的：

db = web.database(dbn = "sqlite",                   db = "./db.sqlite")

但对于postgresql却是另外一个样子:

db = web.database(dbn='postgres',                   host="127.0.0.1",                   port=5432,                   user="postgres",                   password="postgres",                   database="test")

当然，对于sqlite也可以传成database = "./db.sqlite"，但能不能少点儿各自的特性？这是否也违反了python一直提倡的Zen？There should be one-- and preferably only one --obvious way to do it.？？

对于借口的统一性咱先不说了，先说一下web.database中的另一恶心事，SqliteDB！

对于大多数程序员来说，比较常见的代码可能是这个样子：

user = db.select('auth_user',             where = 'user_login = $login',             vars = {
   'login': "admin"}         ) if not len(user): return None

但在使用SqliteDB时程序却会说 user的__len__方法不存在，查看webpy源码，db.select()返回的对象类型为IterBetter，在web.database 的DB::query() 方法中已经对__len__做了明确说明，代码如下：

if db_cursor.description:             names = [x[0] for x in db_cursor.description] def iterwrapper():                 row = db_cursor.fetchone() while row: yield storage(dict(zip(names, row)))                     row = db_cursor.fetchone()             out = iterbetter(iterwrapper())             out.__len__ = lambda: int(db_cursor.rowcount)             out.list = lambda: [storage(dict(zip(names, x))) \ for x in db_cursor.fetchall()]

但在SqliteDB::query()中却对DB::query()方法进程了重载，将len()方法删除，代码如下：

def query(self, *a, **kw):         out = DB.query(self, *a, **kw) if isinstance(out, iterbetter): del out.__len__ return out

究其原因，也许是作者考虑到sqlite在查询时的db_cursor.rowcount一直返回-1，__len__() = -1 对应用来说没有意义吧。

但只要做的后果就是如果开发者想通过web.database做到兼容几个数据库，比如同时支持sqlite和postgresql的话，就无法使用len(user)操作，因为在PostgresDB的query中返回的IterBetter存在len()方法，但在SqliteDB的query中返回的IterBetter却不存在len()方法，这样一来，为了做到通用，除非在程序中显示区分postgres还是sqlite，或者采用以下变通的方式来做：

user = user.list() if not len(user): return None

就为了一个小小的len操作符，至于绕那么大一个弯子么？

其实在webpy中对这一问题进行修正也是很简单的，但目前看来还没有修正的趋势，至少0.35 和 0.36都没有对这一问题修正。

如果开发者不需要考虑数据库的通用性问题，还是不要使用webpy的web.database了吧，目前来看web.database没什么实际价值。如果要考虑数据库之间的兼容性，可以采用SQLAlchemy