On Tuesday 04 January 2011, 14:08:11 Phil Thompson wrote: > The problem... > > v2 of the QVariant API (the default for Python v3) eliminates > QVariant as a Python type. Python objects are converted to and from > C++ QVariants automatically as and when required. An invalid C++ > QVariant is converted to and from None. The problem is that there is > currently no way to represent a null C++ QVariant as a Python object. > This is particularly an issue when using the Qt SQL classes. > > The proposed solution... > > A new Python type, QPyNullVariant, will be implemented (as a mapped > type) which will automatically be converted to and from a null C++ > QVariant. > > Its __init__ method will take a single argument that is either a > Python type object or a string describing a C++ type. > > It will have type(), typeName() and userType() methods that will > delegate to the QVariant's method of the same name. > > It will have a isNull() method that always returns True. > > When converting a C++ QVariant to a Python object a null QVariant > will be converted to a QPyNullVariant unless the type of the data in > the QVariant has an isNull() method. The exception to this rule is a > null QString which, even though it has an isNull() method, will be > converted to a QPyNullVariant. (The reason for the exception is > because - for very good reasons - PyQt converts a null QString to an > empty unicode/str object.) > > This conversion rule means that existing code that populates models > will continue to work. For example, when a null QDate is added to a > model, it will still be read as a null QDate. It also means that the > object retrieved from an SQL model should always have an isNull() > method that returns the correct value. > > The rule introduces an incompatibility for models that may be > populated from C++, typically SQL data. For example a null value in > an int column of an SQL table will now be returned as a > QPyNullVariant rather than an integer with the value 0. This > compatibility is considered acceptable, because the current > implementation is arguably broken anyway, and will be addressed by a > "potential incompatibilities" section in the documentation. (The > alternative would be to introduce v3 of the QVariant API.)
This sounds like a reasonable fix to the problem. Those, that populate their databases with wrapped C++ instances should be able to solve this slight incompatibility themself, but I guess, that such users doesn't exist anyway. For those, that are interested in fixing the related problem of the inability to use invalid dates and times with QDateEdit/QTimeEdit might want to vote for: http://bugreports.qt.nokia.com/browse/QTBUG-277 which is a major PITA in this respect (probably the last). Pete _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt