<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 19:15, J Barchan <span dir="ltr"><<a href="mailto:jnbarchan@gmail.com" target="_blank">jnbarchan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div style="font-family:tahoma,sans-serif"></div><div class="gmail_extra"><br></div><div class="gmail_quote">On 3 May 2018 at 18:24, 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:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div class="m_5884636278982257570HOEnZb"><div class="m_5884636278982257570h5">On 3 May 2018, at 6:16 pm, J Barchan <<a href="mailto:jnbarchan@gmail.com" target="_blank">jnbarchan@gmail.com</a>> wrote:<br>
> <br>
> <br>
> <br>
> On 3 May 2018 at 18:01, Phil Thompson <<a href="mailto:phil@riverbankcomputing.com" target="_blank">phil@riverbankcomputing.com</a>> wrote:<br>
> On 3 May 2018, at 5:32 pm, J Barchan <<a href="mailto:jnbarchan@gmail.com" target="_blank">jnbarchan@gmail.com</a>> wrote:<br>
> > <br>
> > 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.)<br>
> > <br>
> > Phil<br>
> > <br>
> > Hi Phil,<br>
> > <br>
> > Thanks, I knew about the return value from sip.enableautoconversion()<wbr>, I was going to put in your suggestion when I had a moment.<br>
> > <br>
> > 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>
> > <br>
> > 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(QtCo<wbr>re.QVariant, False), which neither I nor anyone else would have known we were supposed to do here.<br>
> <br>
> I disagree with that - although I'm not saying that the documentation couldn't be improved.<br>
> <br>
> > 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?<br>
> <br>
> Anywhere that a null QVariant has a specific meaning and is being passed as an argument to a virtual function.<br>
> <br>
> > 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.)<br>
> > <br>
> > 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>
> <br>
> By context I mean the QtSql module.<br>
> <br>
> 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.<br>
> <br>
> Phil<br>
> <br>
> <br>
> By context I mean the QtSql module.<br>
> <br>
> <br>
> Yes, OK, I did mean "another function in the QtSql module"<br>
> <br>
> > 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?<br>
> <br>
> Anywhere that a null QVariant has a specific meaning and is being passed as an argument to a virtual function.<br>
> <br>
> 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....<br>
> <br>
> 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.<br>
> <br>
> 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?<br>
> <br>
> 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:<br>
> <br>
> 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?].<br>
> <br>
> 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!!<br>
<br>
</div></div>There are *two* issues.<br>
<br>
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.<br>
<br>
The other is a bug which (at the moment) is theoretical, ie. I'm not aware of a Qt call that would be affected.<br>
<br>
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.<br>
<span class="m_5884636278982257570HOEnZb"><font color="#888888"><br>
Phil</font></span></blockquote></div></div></div><div class="gmail_extra"><br><div style="font-family:tahoma,sans-serif">Brilliant, had not appreciated that, much clearer.</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">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.</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Thanks for all your time.</div><span class="HOEnZb"><font color="#888888"><br clear="all"></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"><br>-- <br></div><div class="m_5884636278982257570gmail_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 class="gmail_extra">
</div></font></span></div>
</blockquote></div><br><div style="font-family:tahoma,sans-serif" class="gmail_default">Now I'm finding that, with the fix discussed, while my overridden function definition correctly handles database <span style="font-family:monospace,monospace">NULL</span>s, it "goes wrong" (as in, different behaviour from before) in certain other cases, returning a <span style="font-family:monospace,monospace">QVariant</span> where it did not do so before (it returned the converted, native Python type).</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">1. So long as I do not override <span style="font-family:monospace,monospace">QSqlQueryModel.data()</span> at all, there is absolutely no problem --- both database <span style="font-family:monospace,monospace">NULL</span> and auto-conversion of non-<span style="font-family:monospace,monospace">NULL</span> to Python native type work fine, and are distinct. <i>This is the situation I need.</i></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><i><br></i></div><div style="font-family:tahoma,sans-serif" class="gmail_default">2. I need to override <span style="font-family:monospace,monospace">QSqlQueryModel.data()</span> for my own purposes. If I write just:</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><pre style="background-color:rgb(255,255,255);color:rgb(0,0,0);font-family:"DejaVu Sans Mono";font-size:9pt"><span style="color:rgb(0,0,128);font-weight:bold">def </span>data(<span style="color:rgb(148,85,141)">self</span>, index: QtCore.QModelIndex, role=QtCore.Qt.DisplayRole) -> typing.Any:<br> value = <span style="color:rgb(0,0,128)">super</span>().data(index, role)<br> <span style="color:rgb(0,0,128);font-weight:bold">return </span>value</pre>Some data conversion happens, such that I no longer get NULL back where the value is NULL --- instead it is converted to <span style="font-family:monospace,monospace">''</span> if <i>string</i> or <span style="font-family:monospace,monospace">0</span> if <i>int</i>. <i>This was my original problem and is not acceptable.</i></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><i><br></i></div><div style="font-family:tahoma,sans-serif" class="gmail_default">3. Following our discussion, I change that to:</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><pre style="background-color:rgb(255,255,255);color:rgb(0,0,0);font-family:"DejaVu Sans Mono";font-size:9pt"><span style="color:rgb(0,0,128);font-weight:bold">def </span>data(<span style="color:rgb(148,85,141)">self</span>, index: QtCore.QModelIndex, role=QtCore.Qt.DisplayRole) -> typing.Any:<br><span style="color:rgb(128,128,128);font-style:italic"> </span>was_enabled = sip.enableautoconversion(QtCore.QVariant, <span style="color:rgb(0,0,128);font-weight:bold">False</span>)<br> value = <span style="color:rgb(0,0,128)">super</span>().data(index, role)<br> sip.enableautoconversion(QtCore.QVariant, was_enabled)<br> <span style="color:rgb(0,0,128);font-weight:bold">return value</span></pre>Now I correctly get whatever for database NULL, which works. <i>However</i>, 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.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">So, what I need is: code which allows me to override <span style="font-family:monospace,monospace">QSqlQueryModel.data()</span> but returns the original <span style="font-family:monospace,monospace">data()</span> value <i>unchanged</i>, 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 <span style="font-family:monospace,monospace">QSqlQueryModel.data()</span> does.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">(In PyQt 5.7) <b><i>What exact code can I put into the override to achieve just that, please?</i></b> Surely that can be done, no?<br></div><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>