在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