[PyQt] PyQt 5.7, QSqlQueryModel.data() sub-classed override bug?

J Barchan jnbarchan at gmail.com
Tue May 8 09:04:00 BST 2018 

On 3 May 2018 at 19:15, J Barchan <jnbarchan at gmail.com> wrote:

> ​
>
> On 3 May 2018 at 18:24, Phil Thompson <phil at riverbankcomputing.com> wrote:
>
>> On 3 May 2018, at 6:16 pm, J Barchan <jnbarchan at gmail.com> wrote:
>> >
>> >
>> >
>> > On 3 May 2018 at 18:01, Phil Thompson <phil at riverbankcomputing.com>
>> wrote:
>> > On 3 May 2018, at 5:32 pm, J Barchan <jnbarchan at gmail.com> wrote:
>> > >
>> > > ​​Very few contexts in Qt care about null QVariants - this may well
>> be the only one.​​ (An invalid QVariant - which mapped to None - is much
>> more common.)
>> > >
>> > > Phil
>> > >
>> > > ​Hi Phil,
>> > >
>> > > Thanks, I knew about the return value from
>> ​​​​sip.enableautoconversion(), I was going to put in your suggestion
>> when I had a moment.
>> > >
>> > > As you have shown it is not necessary in this case. However you would
>> have problems for virtual re-implementations that are passed a QVariant as
>> an argument rather than being passed back as a result.
>> > >
>> > > I don't get this, or we are not quite talking the same language.
>> Until we spotted this issue, the Python override function was causing the
>> wrong result to be returned.  We did have to do something in this case: we
>> had to make a call to ​sip.enableautoconversion(QtCore.QVariant, False),
>> which neither I nor anyone else would have known we were supposed to do
>> here.
>> >
>> > I disagree with that - although I'm not saying that the documentation
>> couldn't be improved.
>> >
>> > > I don't mind how we phrase it, but I just need to know what pattern I
>> might need to look out for if I'm supposed to do similar somewhere else in
>> Qt/PyQt?
>> >
>> > Anywhere that a null QVariant has a specific meaning and is being
>> passed as an argument to a virtual function.
>> >
>> > > Very few contexts in Qt care about null QVariants - this may well be
>> the only one.​ (An invalid QVariant - which mapped to None - is much more
>> common.)
>> > >
>> > > I'll take your word for it.  All I would say is that this seems to
>> have come about because we are trying to handle the return of NULL from a
>> database --- right?  Might there not be more functions among all the
>> data-handling ones where this occurs?
>> >
>> > ​​By context I mean the QtSql module.
>> >
>> > PyQt's behaviour is a compromise that works in 90+% of cases without
>> having to use autoenableconversion(). Between us we have identified a case
>> where using autoenableconversion() wouldn't solve the problem. However I'm
>> not sure there is an example in Qt.
>> >
>> > Phil
>> >
>> > ​​
>> > By context I mean the QtSql module.​
>> >
>> >
>> > ​Yes, OK, I did mean "another function in the QtSql module"​
>> >
>> > ​> I don't mind how we phrase it, but I just need to know what pattern
>> I might need to look out for if I'm supposed to do similar somewhere else
>> in Qt/PyQt?
>> >
>> > Anywhere that a null QVariant has a specific meaning and is being
>> passed as an argument to a virtual function.
>> >
>> > ​This could be very important,  I wonder if you're expecting me to
>> understand/be aware of something which you are but I am not....
>> >
>> > I believed what we/I had discovered, specifically in my code not some
>> other code people might write, was a BUG.  And you were going to fix in
>> next version so that I should not have to use the
>> ​sip.enableautoconversion() I have had put in.
>> >
>> > I now wonder whether I have been laboring under a misapprehension, and
>> in fact you are saying my case is effectively expected behaviour, not bug,
>> and the sip.enableautoconversion() I have put in is meant to be there, now
>> and in the future.  Is that the case, could you be very explicit about this
>> kindly?
>> >
>> > Unlike the other guy you were debating with in 2016, I'm not wanting to
>> argue with you about what is best or not.  I just want to know what I need
>> to do to work properly.  I may or may not like it, but if I have to keep an
>> eye out for:
>> >
>> > Anywhere that a null QVariant has a specific meaning and is being
>> passed as an argument to a virtual function [EDIT: or returned from one in
>> the case I show, right?].
>> >
>> > and that's my responsibility and I may have to use
>> sip.enableautoconversion() explicitly in places, at least I know what's
>> expected from me!!
>>
>> There are *two* issues.
>>
>> The one that you actually hit is not a bug - it is the expected
>> behaviour. The solution is to use autoconversionenabled() as you are now
>> doing.
>>
>> The other is a bug which (at the moment) is theoretical, ie. I'm not
>> aware of a Qt call that would be affected.
>>
>> If I fixed the bug then it would also change the behaviour so that you
>> wouldn't need to use autoconversionenabled() - but it wouldn't matter if
>> you still did.
>>
>> Phil
>
>
> ​Brilliant, had ​not appreciated that, much clearer.
>
> I have one further clarification to request.  However, I shall
> deliberately not ask you now, as I think you deserve an evening's rest,
> wherever you are in the world! :)  If I may, I'll ask you tomorrow.
>
> Thanks for all your time.
>
>
> --
> Kindest,
> Jonathan
>

​Now I'm finding that, with the fix discussed, while my overridden function
definition correctly handles database NULLs, it "goes wrong" (as in,
different behaviour from before) in certain other cases, returning a
QVariant where it did not do so before (it returned the converted, native
Python type).​

1. So long as I do not override QSqlQueryModel.data() at all, there is
absolutely no problem --- both database NULL and auto-conversion of non-NULL
to Python native type work fine, and are distinct.  *This is the situation
I need.*

2. I need to override QSqlQueryModel.data() for my own purposes.  If I
write just:

def data(self, index: QtCore.QModelIndex, role=QtCore.Qt.DisplayRole)
-> typing.Any:
    value = super().data(index, role)
    return value

Some data conversion happens, such that I no longer get NULL back where the
value is NULL --- instead it is converted to '' if *string* or 0 if
*int*.  *This
was my original problem and is not acceptable.*

3. Following our discussion, I change that to:

def data(self, index: QtCore.QModelIndex, role=QtCore.Qt.DisplayRole)
-> typing.Any:
    was_enabled = sip.enableautoconversion(QtCore.QVariant, False)
    value = super().data(index, role)
    sip.enableautoconversion(QtCore.QVariant, was_enabled)
    return value

Now I correctly get whatever for database NULL, which works.  *However*,
some other path of code, on some quite different non-NULL value, gets back
a QVariant where it used to get a string.  I don't know what that path of
code is, but I don't think I should care.

So, what I need is: code which allows me to override QSqlQueryModel.data()
but returns the original data() value *unchanged*, just like it used when I
did not put any override in (case #1).  It must do whatever to correctly
deal with NULL & non-NULL, just like the non-overridden
QSqlQueryModel.data() does.

(In PyQt 5.7) *What exact code can I put into the override to achieve just
that, please?*  Surely that can be done, no?


-- 
Kindest,
Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20180508/7ebbe6c8/attachment.html>

More information about the PyQt mailing list