Hi Luigi (Gino),
On Fri, Jun 14, 2013 at 12:00 AM, Gino Pirelli <[email protected]> wrote:
> returnCheck = true
> try:
> returnValue = variable
> except ValueError:
> returnCheck = false
>
the previous code doesn't raise any ValueError without an explicit cast.
If conversion goes wrong you should get None (at least with the latest
API changes), so the check just becomes:
<code>
returnCheck = returnValue is not None
</code>
Another way is to add an explicit cast (e.g. to float):
<code>
try:
returnValue = float(variable)
except ValueError:
returnCheck = false
</code>
> ps: I hope my is English is enough understandable
>
it's surely better than mine ;)
Cheers.
>
> On Sun, Jun 9, 2013 at 4:42 PM, Matthias Kuhn <[email protected]>wrote:
>
>> 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
>>
>
>
> _______________________________________________
> Qgis-developer mailing list
> [email protected]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
--
Giuseppe Sucameli
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
