[OT-ish] Design principles: no bool arguments

[Terry Reedy]

On 8/25/2011 3:13 AM, Steven D'Aprano wrote:
> One design principle often mentioned here (with a certain degree of
> disagreement[1]) is the idea that as a general rule, you shouldn't write
> functions that take a bool argument to switch between two slightly
> different behaviours.
>
> This is a principle often championed by the BDFL, Guido van Rossum.

You missed the essential caveat to his rule. See below.

> Here's a Javascript-centric article which discusses the same idea, and gives
> it a name: the Boolean Trap.
>
> http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html

This was mostly about defining parameters as positional-only (which 
Python does not have) versus keyword-optional or keyword only. In 
Python, callers always have the 'keyword = BOOL' option.

> No doubt there are counter arguments as well. The most obvious to me is if
> the flag=True and flag=False functions share a lot of code, it is poor
> practice to implement them as two functions with two copies of almost
> identical code.
>
> My solution to this is a technical violation of the "Avoid Boolean Trap"
> principle, but only in a private function:
>
> def spam_on(arg):
>       _spam(arg, True)
>
> def spam_off(arg):
>       _spam(arg, False)
>
> def _spam(arg, flag):
>      do stuff
>      if flag:
>          a
>      else:
>          b
>      more stuff

As I think one of the comments pointed out, this now means that if I the 
user need to compute whether to turn off or on, I now have to write

if expr: spam_on(arg)
elses: spam_off(arg)

(or put this on 4 lines if you prefer ;-) instead of

spam_switch(expr, arg)

so moving the conditional out of the function *pushes it onto every 
user*. Note that naming the function 'switch' and putting the bool as 
the first param makes it pretty obvious that True=='on', and False=='off'.

As I remember, Guido only recommendeds splitting if the boolean arg is 
(would be) always (nearly) passed as a constant True or False. Of 
course, I am not sure how one forsees that at the design stage, prior to 
field use.

-- 
Terry Jan Reedy