From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Christopher Larson <clarson@kergoth.com>
Cc: openembedded-architecture
<openembedded-architecture@lists.openembedded.org>,
bitbake-devel <bitbake-devel@lists.openembedded.org>,
Otavio Salvador <otavio.salvador@ossystems.com.br>
Subject: Re: [Openembedded-architecture] [PATCH] data_smart: Drop default expand=False to getVar [API change]
Date: Wed, 03 Feb 2016 16:38:10 +0000 [thread overview]
Message-ID: <1454517490.27087.199.camel@linuxfoundation.org> (raw)
In-Reply-To: <CABcZANkuuQRW7ab_ai=KpoL2030H__kyFszZpkvgkxurmu63_w@mail.gmail.com>
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.
Cheers,
Richard
next prev parent reply other threads:[~2016-02-03 16:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-02 23:55 [PATCH] data_smart: Drop default expand=False to getVar [API change] Richard Purdie
2016-02-03 10:11 ` [Openembedded-architecture] " Otavio Salvador
2016-02-03 11:22 ` Richard Purdie
2016-02-03 15:06 ` Martin Jansa
2016-02-03 16:22 ` Richard Purdie
2016-02-03 16:29 ` Christopher Larson
2016-02-03 16:38 ` Richard Purdie [this message]
2016-02-03 16:52 ` Christopher Larson
2016-02-03 16:43 ` Otavio Salvador
2016-02-06 6:38 ` Paul Eggleton
2016-02-06 9:22 ` Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1454517490.27087.199.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=bitbake-devel@lists.openembedded.org \
--cc=clarson@kergoth.com \
--cc=openembedded-architecture@lists.openembedded.org \
--cc=otavio.salvador@ossystems.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.