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

[Gino Pirelli]

Hi I'm Luigi Pirelli

I'm porting rt_mapserver_export to the new 2.0 SIP api

I found another case where it's necessary to pay attention (and could be
added in the wiki:
http://hub.qgis.org/wiki/quantum-gis/Python_plugin_API_changes_from_18_to_20

as the case before about floats, a simple replace could create problems
because

variable.to<Type> returns a tuple (value, <check on value[true|fase]>)

so, in case in the old style plugin, the code has this (as in
rt_mapserver_export)

(returnValue, returnCheck) = variable.to<type>

doing upgrade to 2.0 as in wiki page produce

(returnValue, returnCheck) = variable   # <--- generates a unique value or
exception

instead of a tuple

generate a runtime error: "ValueError: too many values to unpack"

so the wiki could show another option like this one:

before
(returnValue, returnCheck) = variable.to<type>

after
returnValue = variable
returnCheck = isinstance(variable, <type>)

or

returnCheck = true
try:
      returnValue = variable
except ValueError:
      returnCheck = false

I didn't check for all the types

ciao Luigi Pirelli

ps: I hope my is English is enough understandable


On Sun, Jun 9, 2013 at 4:42 PM, Matthias Kuhn <matthias.kuhn at gmx.ch> 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 <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
> >>>
> >>>
> >>
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130614/dfdfc94e/attachment.html>