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

[Victor Olaya]

I think it is a good idea to force the data type using str(),
unicode(), int(), float(), etc... Maybe a bit redundant, but probably
a safer strategy now



2013/6/9 Matthias Kuhn <matthias.kuhn at gmx.ch>:
> 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
>>>>
>>>>
>>>
>
>