[PyQt] Proposal for QPyNullVariant

[Phil Thompson]

On Tue, 4 Jan 2011 15:27:33 +0100, Detlev Offenbach
<detlev at die-offenbachs.de> wrote:
> On Dienstag, 4. Januar 2011, 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.)
>> 
>> Comments welcome...
>> 
> 
> How shall the data method of QAbstractItemModel subclasses be written.
> With 
> QVariant v1 API a QVariant() is returned to indicate, that no data is 
> available. With the v2 API a None is returned. Should all this code be 
> changed? And how will all the connected views behave?

None will still be returned as that is an invalid QVariant not a null
QVariant.

Phil