[PyQt] PyQt API 2: equivalent of Null QVariant?
phil at riverbankcomputing.com
Wed Dec 22 11:22:26 GMT 2010
On Wed, 22 Dec 2010 11:56:20 +0100, "Hans-Peter Jansen" <hpj at urpla.net>
> 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>
>> > 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
>> > 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
>> 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
> #include <QtCore>
> int main(int argc, char * argv)
> // inconsistent Qt API behavior:
> // Qt should distinguish between QString::null and QString("")
> QString s; // = QString::null;
> 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
I would be more receptive to introducing a new type (eg. QPyNullVariant)
to the QVariant v2 API that wrapped a null QVariant.
More information about the PyQt