[Qgis-developer] SIP API Update merged. Attention plugin authors

[Matthias Kuhn]

Just found another case which requires special attention:

Given a feature with myInt=5

Old API:
> feat['myInt'].toFloat() / 10
> 0.5

New API:
> feat['myInt'] / 10
> 0

Better:
> float( feat['myInt'] ) / 10
> 0.5

Or:
> feat['myInt'] / 10.0
> 0.5

I guess that's not something we can fix in a generic way, but something 
to keep in mind when updating a plugin.

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