<[EMAIL PROTECTED]> wrote: ... > In this case, could be reasonable add type checking LBYL style > on the methods, so if passed data is of wrong type, it generates a > adequate exception to be catched by the caller? In this way, the rest
As maybe one of the first popular authors to use LBYL and EAFP in this sense, I think I should comment here. First, I don't agree with SQLite's design decision to be typeless -- I believe types are important in RDB's in a very different way to their limited importance in programs (where Python's "duck typing almost everywhere" suits me just fine, though some intermediate approach like Boo's might be even better). Nevertheless, SQLite is a good job and I use it happily... when I _don't_ particularly care for type issues. When I _do_ care -- I go back to PostgreSQL. It may not be quite as handy as SQLite, if you want a self-contained program to deploy as a unit... but in just about all other respects, it's got huge advantages. Do consider it -- it will do a better job protecting your data's integrity (among which type-checking of specific fields is just a beginning). For _valuable_ data, where integrity really matters, that's really a big point. ((Oracle, IBM DB2, SAP/DB, Firefly, and no doubt others, might be just as good as PostgreSQL... but I have a sweet spot for the latter; for MySQL, even though I do have to use it sometimes for work purposes, my sympathy on the other hand is pretty low indeed)). If you decide PostgreSQL is not worth the bother, then I think that's a good sign that you should avoid type-checking in your code anyway, as it indicatres that SQLite's "typeless data" approach may be OK for you. Alex -- http://mail.python.org/mailman/listinfo/python-list
