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

[Hans-Peter Jansen]

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;
}


Pete