Re: [libgpiod v2][PATCH v3 2/4] bindings: python: add examples

[Kent Gibson <warthog618@gmail.com>]

On Tue, Oct 18, 2022 at 12:09:10AM +0800, Kent Gibson wrote:
> On Mon, Oct 17, 2022 at 05:53:52PM +0200, Bartosz Golaszewski wrote:
> > On Mon, Oct 17, 2022 at 4:19 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > On Mon, Oct 17, 2022 at 10:07:17PM +0800, Kent Gibson wrote:
> > > > On Mon, Oct 17, 2022 at 04:49:55PM +0300, Andy Shevchenko wrote:
> > > > > On Mon, Oct 17, 2022 at 08:11:28PM +0800, Kent Gibson wrote:
> > > > > > On Mon, Oct 17, 2022 at 02:00:15PM +0200, Bartosz Golaszewski wrote:
> > > > > > > On Thu, Oct 13, 2022 at 5:09 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > > > > > > On Fri, Oct 07, 2022 at 04:55:19PM +0200, Bartosz Golaszewski wrote:
> > >
> > > ...
> > >
> > > > > > > >         lvs = [ arg.split('=') for arg in sys.argv[2:] ]
> > > > > >             lvs = [ (x,int(y)) for (x,y) in lvs ]
> > > > > > > >         lines = [ x[0] for x in lvs ]
> > > > > > > >         values = dict(lvs)
> > > > > > >
> > > > > >
> > > > > > An extra pass to fix the int values.
> > > > >
> > > > > In Python we have map(), which I think is the best for that kind of job.
> > > > >
> > > >
> > > > My understanding is map/filter is old school and list comprehensions
> > > > have replaced map, as generators have replaced filter.
> > > >
> > > > i.e.
> > > >     list(map(function, iterable))
> > > > becomes
> > > >     [function(x) for x in iterable]
> > >
> > > Definitely it does not cover all the cases map() is taking care of.
> > > So it can't be old school :-)
> > >
> > > * Yes, in this particular case it may be map() or list comprehension.
> > >   But I think with map() the two lines can become one.
> > >
> > > > Either way, what we are missing here is a parser function that gives us
> > > > exactly the (offset,value) output we want from the command line string.
> > > >
> > > > Oh, and we need both the lines list and the values dict, both of which
> > > > are easily created from the interim lvs.
> > > >
> > > > > > You could do it in one with a more appropriate parser function.
> > > > >
> > > > > It seems we need some Python guru to revisit the code, because to me
> > > > > it looks a bit C:ish :-)
> > > >
> > > > The for loop or the list comprehension?
> > > > Last I checked only one of those is available in C.
> > > > And yeah, the for loop version reads as C, so not at all Pythonic,
> > > > which is why I suggested the list comprehension.
> > >
> > > Yes, but I believe it does not utilize the powerfulness of the current Python.
> > > Anyway, I'm not a Py guru, take my remarks with a grain of salt.
> > >
> > 
> > How about this?
> > 
> >     lvs = list(
> >         map(
> >             lambda val: [val[0], Value(int(val[1]))],
> >             [arg.split("=") for arg in sys.argv[2:]],
> >         )
> >     )
> 
> which is the same as
> 
>     lvs = [ (x,Value(int(y))) for (x,y) in [ arg.split("=") for arg in sys.argv[2:]] ]
> 
> which is the same as my two liner, just nested - though it may only
> iterate through the list once if the inner list comprehension is
> treated as a generator.  Not sure.
> 
> Either way, not too fussed - it is only example code.
> As long as it isn't a for loop ;-).
> 

Oh, btw, the parser fn version would be something like:

def parse_value(arg):
     (x,y) = arg.split("=")
     return (x, Value(int(y)))

lvs = [ parse_value(arg) for arg in sys.argv[2:]
...

Is that clearer?

Cheers,
Kent.