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 <madman...@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.k...@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 <vola...@gmail.com >>>> <mailto:vola...@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 <rdmaili...@duif.net >>>> <mailto:rdmaili...@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@lists.osgeo.org >>>> <mailto:Qgis-developer@lists.osgeo.org> >>>> > http://lists.osgeo.org/mailman/listinfo/qgis-developer >>>> _______________________________________________ >>>> Qgis-developer mailing list >>>> Qgis-developer@lists.osgeo.org >>>> <mailto:Qgis-developer@lists.osgeo.org> >>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Qgis-developer mailing list >>>> Qgis-developer@lists.osgeo.org >>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >>> >> _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer