George Sakkis wrote: > [EMAIL PROTECTED] wrote: > > > Sure, errors happen with static typing. After all, the values still > > have to match. Dynamic typing allows for more potential errors and, > > thanks to Murpy's Law, I will have a much bigger problem with data > > integrity. > > If this was a java or c++ list, all this rant would be more > understandable, but bashing dynamic typing in a dynamic language list > seems pointless at best (as this has been beaten to death over and over > again), flamebait at worst.
But I'm not bashing Python's use of dynamic typing. But if the SQL Language Specification says static typing, then static typing it is. Period. > It should be clear by now that there are > two (at least) alternatives: > 1. Validate the data in python before (or at the same time when) > feeding the DB. Data integrity is an issue even with static typing. It's a bigger issue with dynamic typing. > 2. Forget sqlite and use a statically typed DBMS; it's not like there > is a shortage of them. I have no intention of forgetting sqlite simply because it's now part of the standard library. I have now qualms about using it *now* because I understand it better. But reaching that level of understanding was like pulling teeth. Documentation shouldn't talk down to the reader. It's always bad when you confuse the smart people. The ignorant are supposed to be confused. It's job of the documentation to educate the ignorant. Hiding the idiosynchrocies of Sqlite3 from the user who's already familiar with SQL is simply unacceptable. > > Massaging your SQL statements to make up for the lack of type checking > (even if this is always possible) would be a bad idea for more than > one reasons (complexity,portability,performance), so you'd better not > go down this road. > > George -- http://mail.python.org/mailman/listinfo/python-list
