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 <[email protected]>: > 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 <[email protected]>: >>> 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 <[email protected]> >>> 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 <[email protected] >>>>> <mailto:[email protected]>> 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 <[email protected] >>>>> <mailto:[email protected]>>: >>>>> > 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 >>>>> > [email protected] >>>>> <mailto:[email protected]> >>>>> > http://lists.osgeo.org/mailman/listinfo/qgis-developer >>>>> _______________________________________________ >>>>> Qgis-developer mailing list >>>>> [email protected] >>>>> <mailto:[email protected]> >>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Qgis-developer mailing list >>>>> [email protected] >>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >>>> >>>> >>> > > _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
