[PATCH 2 of 7 v3 flags] fancyopts: disallow true as a boolean flag default (API)

Pierre-Yves David pierre-yves.david at ens-lyon.org
Fri Sep 16 10:58:51 EDT 2016



On 09/16/2016 04:33 PM, Augie Fackler wrote:
>
> On Fri, Sep 16, 2016 at 10:29 AM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
> wrote:
>
>
>             On 09/14/2016 05:11 AM, Augie Fackler wrote:
>
>                 # HG changeset patch
>                 # User Augie Fackler <augie at google.com
>                 <mailto:augie at google.com>>
>                 # Date 1472584421 14400
>                 #      Tue Aug 30 15:13:41 2016 -0400
>                 # Node ID 828f260114a3a55e246cb5de434e75bdc782e4ad
>                 # Parent  600be3c9acee0ec14bd19c032cc0480e4501fe8c
>                 fancyopts: disallow true as a boolean flag default (API)
>
>                 This was nonsense, as there's not been a way for the user to
>                 un-specify the flag. Restricting this behavior will open
>                 the door to
>                 some nice fit-and-finish functionality in a later patch,
>                 and shouldn't
>                 break any third party extensions. This is marked as
>                 (API) since it
>                 might break a third party extension, but given the fact
>                 that it was
>                 silly before that's mostly a formality.
>
>
>             I really wish we had details on this as requested in the
>             review of the previous version. Especially because I
>             remember that forbidding 'True' as default was making other
>             improvement hard so I'm not sure why we have to do this.
>
>
>         Err? I'm not sure what you're asking for now, and I definitely
>         didn't understand it on the last go round.
>
>
>     Okay, let me clarified, My question here is:
>
>     Why is this problematic to have default to 'True Value'
>
>
>     You refered this as """These cases are a bit problematic, because we
>     don't really have a way to specify default-true flags""" in
>     https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-September/087968.html
>     <https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-September/087968.html>
>
>     I'm seeing another avatar of this question when you says
>     "Restricting this behavior will open the door to some nice
>     fit-and-finish functionality in a later patch" in the current
>     thread. I would like details on this "nice fit-and-finish" features.
>
>     Does this clarify my question ?
>
>
>
> Sure. The answer (which I can fold into the log message if you think
> it's important) is that because of how opts make it into diffopts, we
> can't rely on opts to not be filled in for a value that was unspecified
> on the command line. Because of that, we need to find a backwards
> compatible way to thread defaults through such that they can be
> identified as defaults. The easy way out is to use None for default and
> False for explicitly-false.

Yes please, fold it into the commit message. This this have been 
confusing me for the last versions this will probably be useful to other.

> I'm open to other solutions on the tri-state, but it's a significant
> piece of work that I don't really want to take on.

Getting the handle of tri-state right in a way to do not install a 
future complex rework for the 'default' to True case seems important to 
me. The amount of work involved does not appear too daunting to me.

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list