[PyQt] PyQt API 2: equivalent of Null QVariant?

[Phil Thompson]

On Wed, 22 Dec 2010 11:56:20 +0100, "Hans-Peter Jansen" <hpj at urpla.net>
wrote:
> On Wednesday 22 December 2010, 07:00:01 Phil Thompson wrote:
>> On Wed, 22 Dec 2010 01:33:49 +0100, "Hans-Peter Jansen"
>> <hpj at urpla.net>
>>
>> wrote:
>> > 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.
>>
>> It's contractual in the sense that I commit (to you lot) not to break
>> compatibility during the lifetime of currently available major
>> versions of PyQt and Python.
>>
>> >> > 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
>                                                  QString::null
>> > QVariants(), which cannot appended to, etc.. Anything else with
>> > significance?
>> >
>> > How about an QVariant API 3 with this behavior?
>>
>> There are two issues, QVariant and QString. I don't believe the
>> QVariant issue is a significant one as it easy to work around and
>> (arguably) the workaround forces you to write code that is easier to
>> understand.
>>
>> The asymmetric behaviour of the v2 conversion between a null QString
>> and a Python unicode/string object is more of a problem as it makes
>> it impossible to distinguish a database NULL value from an empty
>> string. The root cause of this is the fact that QString() creates a
>> null QString rather than an non-null empty QString - and there is not
>> a lot I can do about that.
> 
> What about a QString API 3 variant that returns None, if it encounters 
> QString::null values?
> 
> This would correspond to Pythons expliciteness nicely, doesn't it?
> 
> The only adverse effect, I can think of, is not being able to use None 
> as a string, eg. appending something to None isn't possible, while this 
> is (sadly) possible with Qt and uninitialized QStrings (aka 
> QString::null).  
> 
> #include <QtCore>
> 
> int main(int argc, char * argv[])
> {
>     // inconsistent Qt API behavior:
>     // Qt should distinguish between QString::null and QString("")
>     QString s; // = QString::null;
>     s.append("test");
>     qWarning() << "main: <" << s << ">";
>     return 0;
> }

That's exactly why v3 would be a bad idea. You would have to explicitly
test for None in many cases just because Qt returned QString() instead of
QString("").

I would be more receptive to introducing a new type (eg. QPyNullVariant)
to the QVariant v2 API that wrapped a null QVariant.

Phil