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

[Linos]

El 22/12/10 07:00, Phil Thompson escribió:
> 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
> _______________________________________________
> PyQt mailing list    PyQt at riverbankcomputing.com
> http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Hi,
	i am still using v1 api but, if i am understanding correctly, i will be 
forever, i have created any models and helpers with QtSql to work with databases 
that uses extensively the .isNull() feature of QVariant to know what to update 
and when, and not only with string columns. I have less problem with QString as 
an empty unicode object because i use in the same way getting null than empty 
string.

I think that be pythonic it is overrated in the context of binding of libraries 
of other languages.

Regards,
Miguel Angel.