On Tuesday 21 December 2010, 23:58:39 Erik Janssens wrote: > you could just access sql through python instead of through qt, > NULL would then correspond to None
...by the price of renouncing QtSql neck and crop. That's a high price to pay, isn't it? Sure, Camelot does this, but I really appreciate displaying tables with a million records with a few lines of code without any worry (thanks to Qt's decent fetch mechanics under the model/view covers). > On Tue, 2010-12-21 at 23:52 +0100, TP wrote: > > Phil Thompson wrote: > > > API v1 will be supported until PyQt5 or Python v4. > > > > Is it contractual? Why Python v4? It seems to me that nobody knows > > when Python v4 will appear. > > Anyway, it seems to be a problem that API2 does not support NULL, > > even if it corresponds to side cases (as mine). This is unfortunate, since sacrificing API 2 QVariants is a long ranging decision to better make _early_ on - changing it lately in a project will cause headaches, guaranteed (apart from the unpythonic annoyance, that let to inventing it in the first place). The question is, what would be the prize of getting away from that asymmetry? PyQt would always return None for QString::Null QVariants(), which cannot appended to, etc.. Anything else with significance? How about an QVariant API 3 with this behavior? Pete _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt