<div dir="ltr">Hi I'm Luigi Pirelli<div><br></div><div>I'm porting rt_mapserver_export to the new 2.0 SIP api</div><div><br></div><div>I found another case where it's necessary to pay attention (and could be added in the wiki:</div>



<div><a href="http://hub.qgis.org/wiki/quantum-gis/Python_plugin_API_changes_from_18_to_20" target="_blank">http://hub.qgis.org/wiki/quantum-gis/Python_plugin_API_changes_from_18_to_20</a></div><div><br></div><div>as the case before about floats, a simple replace could create problems because </div>



<div><br></div><div><a href="http://variable.to" target="_blank">variable.to</a><Type> returns a tuple (value, <check on value[true|fase]>)</div><div><br></div><div>so, in case in the old style plugin, the code has this (as in rt_mapserver_export)</div>



<div><br></div><div>(returnValue, returnCheck) = <a href="http://variable.to" target="_blank">variable.to</a><type> </div><div><br></div><div>doing upgrade to 2.0 as in wiki page produce</div><div><br>
</div><div>(returnValue, returnCheck) = variable   # <--- generates a unique value or exception </div><div>                                                                        instead of a tuple<br></div>
<div><br></div><div>generate a runtime error: "ValueError: too many values to unpack"</div><div><br></div><div>so the wiki could show another option like this one:</div><div><br></div>
<div>before </div><div>(returnValue, returnCheck) = <a href="http://variable.to" target="_blank">variable.to</a><type> <br></div><div><br></div><div>after</div><div>returnValue = variable<br></div><div>
returnCheck = isinstance(variable, <type>)<br></div><div><br></div><div>or</div><div><br></div><div>returnCheck = true<br></div><div>try:</div><div>      returnValue = variable</div>
<div>except ValueError:</div><div>      returnCheck = false</div><div><br></div><div>I didn't check for all the types</div><div><br></div><div>ciao Luigi Pirelli</div><div><br>
</div><div>ps: I hope my is English is enough understandable </div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 9, 2013 at 4:42 PM, Matthias Kuhn <span dir="ltr"><<a href="mailto:matthias.kuhn@gmx.ch" target="_blank">matthias.kuhn@gmx.ch</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Just found another case which requires special attention:<br>



<br>
Given a feature with myInt=5<br>
<br>
Old API:<br>
> feat['myInt'].toFloat() / 10<br>
> 0.5<br>
<br>
New API:<br>
> feat['myInt'] / 10<br>
> 0<br>
<br>
Better:<br>
> float( feat['myInt'] ) / 10<br>
> 0.5<br>
<br>
Or:<br>
> feat['myInt'] / 10.0<br>
> 0.5<br>
<br>
I guess that's not something we can fix in a generic way, but something<br>
to keep in mind when updating a plugin.<br>
<div><div><br>
On Son 09 Jun 2013 16:38:09 CEST, Victor Olaya wrote:<br>
> I find that same behaviour that Matthias confirms.<br>
><br>
> I guess it should be fixed, since it forces developers to add extra<br>
> code to handle that case, and it can be very confusing (all other<br>
> Qvariants are removed, except in this case...)<br>
><br>
> Hopefully it will be easy to fix.<br>
><br>
> Thanks in advance!<br>
> Victor<br>
><br>
> 2013/6/9 Nathan Woodrow <<a href="mailto:madmanwoo@gmail.com" target="_blank">madmanwoo@gmail.com</a>>:<br>
>> Ok I'll check it out and see if it can be converted.<br>
>><br>
>> -- Nathan<br>
>><br>
>><br>
>> On Mon, Jun 10, 2013 at 12:19 AM, Matthias Kuhn <<a href="mailto:matthias.kuhn@gmx.ch" target="_blank">matthias.kuhn@gmx.ch</a>><br>
>> wrote:<br>
>>><br>
>>> On Son 09 Jun 2013 16:02:57 CEST, Nathan Woodrow wrote:<br>
>>>> Victor,<br>
>>>><br>
>>>> Which code is returning a QVariant null?<br>
>>><br>
>>> feat['myAttribute']<br>
>>> returns QPyNullVariant for all features which have a NULL value in the<br>
>>> field myAttribute.<br>
>>><br>
>>> None would work for me as well. But I'm not sure, why PyQt introduced<br>
>>> this new type. Maybe there is a reason?<br>
>>><br>
>>> Matthias<br>
>>><br>
>>>><br>
>>>> - Nathan<br>
>>>><br>
>>>><br>
>>>> On Mon, Jun 10, 2013 at 12:01 AM, Victor Olaya <<a href="mailto:volayaf@gmail.com" target="_blank">volayaf@gmail.com</a><br>
>>>> <mailto:<a href="mailto:volayaf@gmail.com" target="_blank">volayaf@gmail.com</a>>> wrote:<br>
>>>><br>
>>>>     I am checking the SEXTANTE adaptation to the new SIP API, and<br>
>>>>     everything is fine. The only "strange" thing that I found is how<br>
>>>> null<br>
>>>>     values are handled when they appear in a vector layer field. It<br>
>>>> seems<br>
>>>>     that, in that case, a QVariant is still returned (particularly a<br>
>>>>     QPyNullVariant object). Wouldn't it be better to return a Python<br>
>>>> None<br>
>>>>     instead, so in all cases Python values are returned?<br>
>>>><br>
>>>>     Cheers<br>
>>>><br>
>>>>     2013/6/9 Richard Duivenvoorde <<a href="mailto:rdmailings@duif.net" target="_blank">rdmailings@duif.net</a><br>
>>>>     <mailto:<a href="mailto:rdmailings@duif.net" target="_blank">rdmailings@duif.net</a>>>:<br>
>>>>     > On 09-06-13 10:47, Nathan Woodrow wrote:<br>
>>>>     >><br>
>>>>     >> Technically this can be done for smaller plugins like Borys said.<br>
>>>>     >>   Something like:<br>
>>>>     ><br>
>>>>     ><br>
>>>>     > I think only for VERY small plugins. In the (not so very big<br>
>>>>     plugins) I do<br>
>>>>     > it was already getting messy.<br>
>>>>     ><br>
>>>>     > And by the why, a big thank you for all the great work and<br>
>>>>     decisions being<br>
>>>>     > done lately! I really think 2.0 will be great \o/<br>
>>>>     ><br>
>>>>     > Richard<br>
>>>>     ><br>
>>>>     ><br>
>>>>     > _______________________________________________<br>
>>>>     > Qgis-developer mailing list<br>
>>>>     > <a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
>>>>     <mailto:<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a>><br>
>>>>     > <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>>>>     _______________________________________________<br>
>>>>     Qgis-developer mailing list<br>
>>>>     <a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
>>>> <mailto:<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a>><br>
>>>>     <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Qgis-developer mailing list<br>
>>>> <a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
>>>> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>>><br>
>>><br>
>><br>
<br>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</div></div></blockquote></div><br></div></div>