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

[Linos]

El 22/12/10 12:22, Phil Thompson escribió:
> On Wed, 22 Dec 2010 11:56:20 +0100, "Hans-Peter Jansen"<hpj at urpla.net>
> wrote:
>> 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;
>> }
>
> 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
> QString("").
>
> I would be more receptive to introducing a new type (eg. QPyNullVariant)
> to the QVariant v2 API that wrapped a null QVariant.
>
> Phil
> _______________________________________________
> PyQt mailing list    PyQt at riverbankcomputing.com
> http://www.riverbankcomputing.com/mailman/listinfo/pyqt

I think this should be done, it is crucial to work with databases through qt to 
correctly identify null values.

Regards,
Miguel Angel.