And the NULL values? try: a = float(b['c']) except TypeError: a = None
Do you have a more elegant idea? On Son 09 Jun 2013 16:46:42 CEST, Victor Olaya wrote: > 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
