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.