Python bindings

Andrew Bird ajb at spheresystems.co.uk
Fri Nov 16 11:33:11 PST 2012


On Friday 16 November 2012 15:33:52 Aleksander Morgado wrote:
> >>>>> 1/ client.get_manufacturer() won't take None as the first argument,
> >>>>> but
> >>>>> looking at the gir I can't see why not. As a hack I passed in a
> >>>>> function
> >>>>> reference, knowing that its unused anyway.
> >>>> 
> >>>> Maybe some missing (allow-none) annotation for the 'input' variable in
> >>>> the async call?
> >>>> 
> >>>>> 2/ Where necessary, complex return values should be returned in a
> >>>>> tuple.
> >>>>> If
> >>>>> you look at get_manufacturer_ready() you'll see that supposedly the
> >>>>> value
> >>>>> is returned in the string passed in to arg1. For me that's always
> >>>>> empty,
> >>>>> but I checked with qmicli, the value is populated properly. The page
> >>>>> https://live.gnome.org/PyGObject/IntrospectionPorting suggests that it
> >>>>> should be returning tuples in this case, and its certainly more
> >>>>> pythonic.
> >>>> 
> >>>> Maybe some missing (out) annotation for each variable returned when
> >>>> reading the TLV from the output bundle?
> >>> 
> >>> Hi Aleksander,
> >>> 
> >>>     Given that GetManufacturer is in the generated stuff, where should I
> >>>     apply
> >>> 
> >>> my changes so that they appear in its output?
> >> 
> >> Directly in the code generator sources; under build-aux/qmi-codegen/*.py
> > 
> > Aleksander,
> > 
> >    I've found and made the changes and now get output now. One thing
> >    though
> > 
> > the unused parameter instead of 'allow-none', could be 'skip', which seems
> > nicer. On the other hand I'm not sure if you ever intend to use this
> > parameter?
> 
> That's the main problem. Messages defined without input TLVs need the
> NULL input bundle in the API, just in case some day the message is
> updated with a first TLV added. There are definitely cases where this
> will not happen; e.g. GetManufacturer will very likely never need an
> input TLV. But we cannot tell about *all* messages without input TLVs.
> Hence, I would personally leave it as (allow-none) instead of directly
> (skip).
yep, agreed

> 
> > Below are the patches for discussion:
> > 
> > ###############
> > 
> >>From 35b5bb2916b36c17350c3ded24d34b97d4592b2d Mon Sep 17 00:00:00 2001
> >>
> > From: Andrew Bird <ajb at spheresystems.co.uk>
> > Date: Fri, 16 Nov 2012 11:29:39 +0000
> > Subject: [PATCH 1/2] Add annotation to output strings in the generated
> > output
> > 
> > This patch ensures that the bindings recognise that these
> > variables are dealt with as output ones. On Python this
> > changes the calling convention to be more pythonic and enables
> > the value to be returned e.g.
> > 
> > before:
> >         s = ''
> >         v = m.get_manufacturer(s)
> >         # s is still empty
> > 
> > after:
> >         (v, s) = m.get_manufacturer()
> >         # s == "QUALCOMM INCORPORATED"
> > 
> > ---
> > 
> >  build-aux/qmi-codegen/VariableString.py | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/build-aux/qmi-codegen/VariableString.py b/build-aux/qmi-
> > codegen/VariableString.py
> > index a127eb7..96f49f4 100644
> > --- a/build-aux/qmi-codegen/VariableString.py
> > +++ b/build-aux/qmi-codegen/VariableString.py
> > 
> > @@ -258,7 +258,7 @@ class VariableString(Variable):
> >                           'name' : variable_name }
> >          
> >          template = (
> > 
> > -            '${lp}@${name}: a placeholder for the output constant string,
> > or %NULL if not required.\n')
> > +            '${lp}@${name}: (out): a placeholder for the output constant
> > string, or %NULL if not required.\n')
> > 
> >          return string.Template(template).substitute(translations)
> 
> So, this fixes it for strings. The other variable types would need the
> same update. Are you able to add those as well?
yes, can do. Just stumbled upon their usage in uim_get_pin_status

> 
> > --
> > 1.7.11.7
> > 
> > ###################
> > 
> >>From 0147e1fdcb4eeac7cb761ccf7069753f8848b45c Mon Sep 17 00:00:00 2001
> >>
> > From: Andrew Bird <ajb at spheresystems.co.uk>
> > Date: Fri, 16 Nov 2012 11:59:49 +0000
> > Subject: [PATCH 2/2] Allow unused parameters to have null passed in
> > 
> > ---
> > 
> >  build-aux/qmi-codegen/Client.py | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/build-aux/qmi-codegen/Client.py
> > b/build-aux/qmi-codegen/Client.py index 5fa4178..7a95d29 100644
> > --- a/build-aux/qmi-codegen/Client.py
> > +++ b/build-aux/qmi-codegen/Client.py
> > 
> > @@ -286,7 +286,7 @@ class Client:
> >              if message.input.fields is None:
> >                  input_arg_template = 'gpointer unused'
> >                  translations['input_var'] = 'NULL'
> > 
> > -                translations['input_doc'] = 'unused: %NULL. This message
> > doesn\'t have any input bundle.'
> > +                translations['input_doc'] = 'unused: (allow-none): %NULL.
> > This message doesn\'t have any input bundle.'
> > 
> >              else:
> >                  input_arg_template = '${input_camelcase} *input'
> >                  translations['input_var'] = 'input'
> 
> Nothing else to comment abuot this one.
> 
> 
> Some of the things I'm not sure about is which is the default 'transfer'
> mode for variables if none defined. Is it full? or none?
It depends upon the type, but a diff on the updated .gir file shows all outputs 
added have become 'full'
 
> 
> The input and output bundles have new(),ref() and unref(). In the case
> of new() and ref() they should be transfer full; I don't think I added
> those. Then, for all set/get operations in the bundles, the variables
> passed are all transfer-none. So seems to me that either one or the
> other also needs annotation tags to specify the correct transfer mode.
> Are you able to look at that as well?
Not sure about this yet, but I'll have a look.

> 
> 
> You're coming with a good set of patches here :-) If you have a public
> repo somewhere with all these in a branch let me know.

When I get through testing out various things I'll push them up to github.

Andrew



More information about the libqmi-devel mailing list