<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 3, 2016 at 9:38 AM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 2016-02-03 at 09:29 -0700, Christopher Larson wrote:<br>
> > The actual getVar syntax on the other handy is more than cosmetic,<br>
> > people don't understand what this "True" they keep adding means, or<br>
> > why<br>
> > they need it. You tend to know when you don't want expansion on the<br>
> > other hand. So a cleaner syntax which does what the user most<br>
> > likely<br>
> > needs is more than cosmetic.<br>
> I'd agree with that, passing booleans as arguments sucks all around,<br>
> since it loses context. *If* someone is going to do it, it's best to<br>
> pass it with the argument name in keyword form in the caller, and<br>
> obviously we don't want to do that here.<br>
><br>
> That said, I'm rather inclined toward thinking about alternative<br>
> DataSmart APIs in general, in the long term. For example, it's a<br>
> MutableMapping, so it acts dict-like, so we should be able to use<br>
> .get() and get an expanded value, and then the case would line up<br>
> with PEP8 (CamelCase for functions is frowned upon). I.e. we could<br>
> have get() and get_unexpanded().<br>
<br>
</span>I'm just thinking out loud here, I think the above is worth seriously<br>
considering. One big advantage "getVar" has is that its pretty unique<br>
and the python parsing code therefore doesn't get a lot of false<br>
positives with function names. "get" on the other hand, I can see being<br>
a nightmare.</blockquote></div><br></div><div class="gmail_extra">That's a good point, I'll admit I didn't think about the codeparsing in that regard. I wonder how much work it'd be to track what variable(s) hold DataSmart instances.. we know 'd' starts that way, that's an assumption we can make, but it wouldn't traverse createCopy().. *Ponders*<br>-- <br><div class="gmail_signature">Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div>
</div></div>