[Mesa-dev] [PATCH 22/41] glapi: gl_XML.py: convert gl_api.functionIterateByOffset to a generator

Dylan Baker baker.dylan.c at gmail.com
Tue Apr 19 23:32:36 UTC 2016


Quoting Ian Romanick (2016-04-19 16:13:51)
> On 04/01/2016 11:47 AM, Ilia Mirkin wrote:
> > On Fri, Apr 1, 2016 at 2:41 PM, Dylan Baker <baker.dylan.c at gmail.com> wrote:
> >> Quoting Ilia Mirkin (2016-04-01 08:46:19)
> >>> IMHO this is still quite fancy and unnecessarily complicated.
> >>>
> >>> How about
> >>>
> >>>   temp = dict((f.offset, f) for f in self.functions_by_name.itervalues())
> >>>   return (temp[offset] for offset in sorted(temp))
> >>>
> >>> That's all that's happening there, right? This lets you not use yield
> >>> (which is confusing to most people, as Brian points out), but still
> >>> uses a generator to avoid creating that second list, behind the
> >>> scenes, while staying understandable to people who understand list
> >>> comprehensions (which, hopefully, anyone using python by now does...
> >>> they've been around since at least Python 2.2)
> >>>
> >>> [BTW, this is not a complete review of the series... just looking at
> >>> this patch because Brian happened to reply to it.]
> >>
> >> I knew there must be an easier way to do this, I had a different
> >> implementation that was simpler, but didn't sort correctly, before this
> >> one, and I wasn't really happy with this.
> >>
> >> I don't think we actually need to care about max_offset do we? Since
> >> that was more an implementation detail of the original function, I'll
> >> rebase out the previous patch too.
> > 
> > Nope, it's just there to size the array. [From what I can tell.]
> > 
> >> I don't think yours is exactly right though, since it doesn't handle the
> >> offset == -1, but that's trivial.
> > 
> > Er, right, of course. Forgot :) And it's a pretty crucial detail.
> > 
> >> Something like this(?):
> >>
> >> temp = [(f.offset, f) for f in self.functions_by_name.itervalues()
> >>         if f.offset != -1]
> >> return (func for _, func in sorted(temp))
> > 
> > And this has the nice advantage of not creating a dict for no reason.
> > There's the hypothetical issue of 2 functions having the same offset,
> > but... I don't think that's possible in practice.
> 
> Nope.  Offsets are either uniquely, statically assigned in the XML, or
> they're assigned dynamically by the scripts.  If two functions are
> supposed to have the same location, they must be marked as aliases in
> the XML.
> 
> >> I guess we could make one generator comprehension out of it, but
> >> performance isn't that critical (though this does seem to be slightly
> >> faster).
> >>
> >> return (f for f in sorted(self.functions_by_name.itervalues(),
> >>                           key=lambda f: f.offset)
> >>         if f.offset != -1)
> >>
> >>
> >> Which do you think is more readable?
> > 
> > I like the first one, esp since the list it builds for sorting is
> > going to be *much* smaller (I could be wrong, but I think the majority
> > of functions don't have an explicit offset, i.e. end up with -1).
> 
> I like the first one too.  I was pretty sure there was a way to do it
> like that... but my Python skills aren't quite good enough.  I'm glad I
> decided to read the rest of the thread before searching Python websites. :)

Cool, I'll add a comment here that the data guarantees that the offsets
shouldn't collide, and use the first one when I spin the v2.

> 
> > Perhaps Brian should make the call on understandability though, as
> > someone not familiar with the ins and outs of Python? [I,
> > unfortunately(?), crossed that line quite some years back --
> > generators in Py2.4 were the cool new thing.]
> > 
> > Thanks,
> > 
> >   -ilia
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160419/e242b265/attachment.sig>


More information about the mesa-dev mailing list