On Wed, Feb 3, 2016 at 9:38 AM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Wed, 2016-02-03 at 09:29 -0700, Christopher Larson wrote:
> > >  The actual getVar syntax on the other handy is more than cosmetic,
> > > people don't understand what this "True" they keep adding means, or
> > > why
> > > they need it. You tend to know when you don't want expansion on the
> > > other hand. So a cleaner syntax which does what the user most
> > > likely
> > > needs is more than cosmetic.
> > I'd agree with that, passing booleans as arguments sucks all around,
> > since it loses context. *If* someone is going to do it, it's best to
> > pass it with the argument name in keyword form in the caller, and
> > obviously we don't want to do that here.
> >
> > That said, I'm rather inclined toward thinking about alternative
> > DataSmart APIs in general, in the long term. For example, it's a
> > MutableMapping, so it acts dict-like, so we should be able to use
> > .get() and get an expanded value, and then the case would line up
> > with PEP8 (CamelCase for functions is frowned upon). I.e. we could
> > have get() and get_unexpanded().
>
> I'm just thinking out loud here, I think the above is worth seriously
> considering. One big advantage "getVar" has is that its pretty unique
> and the python parsing code therefore doesn't get a lot of false
> positives with function names. "get" on the other hand, I can see being
> a nightmare.


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*
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics