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

[J Barchan]

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

-- 
Kindest,
Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20180503/136a25b9/attachment-0001.html>