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

Phil Thompson phil at riverbankcomputing.com
Wed Dec 22 06:00:01 GMT 2010


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 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.

Phil


More information about the PyQt mailing list