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

[Augie Fackler]

> On Sep 14, 2016, at 11:03, Yuya Nishihara <yuya at tcha.org> wrote:
> 
> On Tue, 13 Sep 2016 23:11:18 -0400, Augie Fackler wrote:
>> # HG changeset patch
>> # User Augie Fackler <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.
> 
> Yes, it was silly before, but now it isn't because we have --no-<opt>.
> We can define ('status', default=True) in place of ('no-status', default=False).
> Though I'm sure we'll need something to mark default-True flags in help, I
> think that will still be simpler than ditching default=True and False.
> 
> For None/False/True tristate, I'd rather make it <empty>/False/True and
> test 'key in opts' explicitly.

Aspirationally I agree, but that's going to be a much more invasive change than I'd really like to deal with right now (lots of commands *depend* on the default being falsy, and having an explicit "unset" value will require a fair amount of cleanup (diffopts and rebase both come to mind as code that will require love, and I'm sure there's a bunch more I didn't see.)