<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 May 2018 at 17:20, Phil Thompson <span dir="ltr"><<a href="mailto:phil@riverbankcomputing.com" target="_blank">phil@riverbankcomputing.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 3 May 2018, at 5:05 pm, J Barchan <<a href="mailto:jnbarchan@gmail.com">jnbarchan@gmail.com</a>> wrote:<br>
> <br>
> <br>
> <br>
> On 3 May 2018 at 16:17, Phil Thompson <<a href="mailto:phil@riverbankcomputing.com">phil@riverbankcomputing.com</a>> wrote:<br>
> On 3 May 2018, at 3:22 pm, J Barchan <<a href="mailto:jnbarchan@gmail.com">jnbarchan@gmail.com</a>> wrote:<br>
> > Hey Phil,<br>
> > <br>
> > Assuming I am not barking up the wrong tree, I see you yourself were discussing this issue in <a href="http://python.6.x6.nabble.com/PyQt5-NULL-QVariant-tp5188782p5190811.html" rel="noreferrer" target="_blank">http://python.6.x6.nabble.com/<wbr>PyQt5-NULL-QVariant-<wbr>tp5188782p5190811.html</a>. It includes:<br>
> > <br>
> > > Can you confirm that returning empty string and 0 for NULL is expected <br>
> > > behavior and not seen as a bug? <br>
> > <br>
> > Yes. If you want to distinguish null QVariants then use sip.enableautoconversion(). The problem is that you are not willing to do that. <br>
> > <br>
> > So I'm bumbling around trying to put a sip.enableautoconversion() in! Trouble is, I don't understand the syntax, and I don't know where to put it (I'm not finding any examples, and you two obviously knew more than me about it :) )<br>
> > <br>
> > 1. I'm assuming I want to suppress converting QVariants. I'm trying <br>
> > sip.enableautoconversion(<wbr>QVariant, False)<br>
> > but it doesn't know what QVariant is, and I don't know if it's supposed to or my syntax or imports or whatever?<br>
> <br>
> Import QVariant from QtCore.<br>
> <br>
> > 2. I don't know where I'm supposed to disable & re-enable the autoconversion? My method is an override called implicitly by Qt.<br>
> > * Is this a "directive" that's supposed to be used e.g. as a Python method is read in, and so belongs around the whole function?<br>
> > * Is this a "run-time* that I just need to put inside my method overload around where it calls the base class method? Or by the time it has hit my overload is it too late because some conversion has already happened?<br>
> > * Do I actually need to put it around the whole of my top-level call to, say, QSqlQueryModel.rowCount(), which is what (I understand to be) invoking calls to the overridden QSqlQueryModel.data() method?<br>
> <br>
> I think you need to do the latter - at least as a workaround for the moment. I need to add a directive to SIP to disable the auto-conversion during the code that handles the virtual and calls the Python re-implementation.<br>
> <br>
> Phil<br>
> <br>
> Hi Phil,<br>
> <br>
> Right, I think we're in business, here goes...!<br>
> <br>
> First, I took your *original* response of "No and no." to indicate that my issue would have nothing to do with PyQt. In the end I think we are agreeing it has turned out to be a PyQt issue after all.<br>
> <br>
> Second, yes, I figured "Import QVariant from QtCore" was what I was missing. (Not helped by PyCharm warning me it really wanted a "sip wrappertype" for sip.enableautoconversion() instead of a "type", but it works OK at run-time.) I actually interpreted <a href="http://pyqt.sourceforge.net/Docs/PyQt5/pyqt_qvariant.html" rel="noreferrer" target="_blank">http://pyqt.sourceforge.net/<wbr>Docs/PyQt5/pyqt_qvariant.html</a>:<br>
> <br>
> v2 (the default for Python v3) does not expose the QVariant class to Python<br>
> <br>
> as meaning that QVariant was not going to be defined/exported in any PyQt file at all. But I see it still is.<br>
> <br>
> Third, in view of your "I think you need to do the latter [put sip.enableautoconversion() around the whole of my top-level call] - at least as a workaround for the moment.", I started out doing that. However, I found that the data() method is being called all over the place (e.g. throughout the QTableView displaying the model), which I guess makes sense, so that was soon a non-starter. In any case it would be way-dangerous to have to change QVariant behaviour across a large area of code. I would hugely prefer to only have to do so across the call to the base method from the derived method, and to my pleasure it seems to be working just fine like that. So my override (to give you a flavor of why I need it) now actually reads:<br>
> <br>
> def data(self, index: QtCore.QModelIndex, role=QtCore.Qt.DisplayRole) -> typing.Any:<br>
> DBModelCommon.<wbr>dataIndexIsValid(index) # do some checking that index is valid<br>
> <br>
> import sip<br>
> sip.enableautoconversion(<wbr>QtCore.QVariant, False)<br>
> value = super().data(index, role) # wrap call to QSqlQueryModel.data() inside no-convert-QVariant-to-Python<br>
> sip.enableautoconversion(<wbr>QtCore.QVariant, True)<br>
> <br>
> return DBModelCommon.dataValue(value, role) # do some (potential) post-processing on the value returned<br>
<br>
</div></div>A more resilient version would be...<br>
<br>
was_enabled = <div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"></div><div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"></div>sip.enableautoconversion(<wbr>QtCore.QVariant, False)<br>
...<br>
sip.enableautoconversion(<wbr>QtCore.QVariant, was_enabled)<br>
<span class=""><br>
> You will understand this better than I, but the implication is that the problem is not in my own Python definition of this override itself already doing a conversion and going wrong, but rather at the time it calls the base function and grabs its return value into Python?<br>
> <br>
> So far all I can say is that from what i have seen it now handles my values --- both NULLs and non-NULLs --- correctly! :)<br>
<br>
> Finally, I'm interested to understand what is going on here, and why you "need to add a directive to SIP to disable the auto-conversion during the code that handles the virtual and calls the Python re-implementation". <br>
<br>
</span>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.<br>
<span class=""><br>
> I'm assuming the override was returning a QVariant-converted-to-Python-<wbr>type, then something about other (Qt) C++ code calling the override and not being happy about the return type, or something? So how do you (or I) know whether there are going to be other cases (overrides) which, say, return or pass or receive a QVariant (which could be a NULL one), and will also fall foul of this issue? Do you/I need to look through every Qt function? Have you already done this and are confident that there can be only a few remaining which you have not spotted? Is that how it works?<br>
<br>
</span><div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"></div>Very few contexts in Qt care about null QVariants - this may well be the only one.<div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"></div> (An invalid QVariant - which mapped to None - is much more common.)<br>
<span class="HOEnZb"><font color="#888888"><br>
Phil</font></span></blockquote></div></div><div class="gmail_extra"><br><div style="font-family:tahoma,sans-serif" class="gmail_default">Hi Phil,</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Thanks, I knew about the return value from <div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"></div><span style="font-family:monospace,monospace">sip.enableautoconversion()</span>, I was going to put in your suggestion when I had a moment.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:tahoma,sans-serif" class="gmail_default">As you have shown it is not necessary in this case. However you would
have problems for virtual re-implementations that are passed a <span style="font-family:monospace,monospace">QVariant</span>
as an argument rather than being passed back as a result.</div></blockquote><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">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 <div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"></div><span style="font-family:monospace,monospace">sip.enableautoconversion(</span><wbr><span style="font-family:monospace,monospace">QtCore.QVariant, False)</span>, which neither I nor anyone else would have known we were supposed to do here. 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?</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Very few contexts in Qt care about null QVariants - this may well be the only one.<div style="font-family:tahoma,sans-serif;display:inline" class="gmail_default"></div> (An invalid QVariant - which mapped to None - is much more common.)</blockquote></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">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?<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Thanks, Phil.</div></div><div class="gmail_extra"><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><span style="font-family:tahoma,sans-serif">Kindest,</span></div><div><span style="font-family:tahoma,sans-serif">Jonathan</span></div></div></div></div></div>
</div></div>