[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