[Python-ideas] Boolean parameters guidelines

[M.-A. Lemburg]

On 09.05.2016 22:07, Guido van Rossum wrote:
> On Mon, May 9, 2016 at 1:00 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> On 09.05.2016 21:47, Guido van Rossum wrote:
>>> On Mon, May 9, 2016 at 12:36 PM, Barry Warsaw <barry at python.org> wrote:
>>>> On May 08, 2016, at 11:59 AM, Steven D'Aprano wrote:
>>>>> I think it is preferable *not* to have boolean parameters at all.
>>>>>
>>>>> I don't remember if this is Guido's name for it, but I remember him
>>>>> expressing the guideline "No constant bool arguments". If you have an
>>>>> argument which takes a bool, and is used solely to switch between two
>>>>> different modes, and the caller will most likely call the function with
>>>>> the argument as a constant known when writing the code (rather than
>>>>> taking an expression or variable with value not known until runtime),
>>>>> then it is usually better to split the function into two, one for
>>>>> each mode.
>>
>> This seems overly strict, e.g. it's not uncommon to have functions
>> enable debugging, verbose processing or similar processing variants
>> using a boolean parameter.
>>
> 
> But usually the call site values for those wouldn't be constant -- they'd
> be computed from a command line flag for example. The key part of the
> phrasing is "the caller will most likely call the function with the
> argument as a constant known when writing the code".

Hmm, so if you'd typically pass in a constant for the parameter
it's deemed poor style, whereas when the value comes from some
variable, it's fine ?

This looks more like an API design question than a coding
style one.

E.g. take this example:

def process(data, raise_errors=True):
    try:
        ...
        return result
    except ValueError:
        if raise_errors:
            raise
        else:
            return None

It's not clear whether the caller would run the function
with raise_errors=True or raise_errors=config.raise_errors
more often.

> FWIW I disagree with the lead-in phrase "I think it is preferable *not* to
> have boolean parameters at all."

Same here.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 09 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
                      http://www.malemburg.com/