[Python-ideas] Boolean parameters guidelines

Guido van Rossum guido at python.org
Tue May 10 20:20:53 EDT 2016


On Tue, May 10, 2016 at 4:59 PM, Joseph Martinot-Lagarde <
contrebasse at gmail.com> wrote:

>
> > I meant that I disagreed in several cases with whether an example was
> Good
> or Bad and I couldn't figure out what rule you were using in your head to
> decide on Good/Bad, IOW what rule you were illustrating with these
> examples.
>
> Alright, I'll add some explanation. I took an example already used in this
> thread to be more clear.
>
>     # Bad: no indication on what the boolean argument does.
>     process(data, True)
>
>     # Good: the boolean is used to indicate that errors are raised.
>     process(data, raise_errors=True)
>

So far so good.


>     # Good: the variable name is used to indicate what the argument means.
>     raise_errors=True
>     process(data, raise_errors)
>

Not so sure. If the variable raise_errors were set to False the process()
call could seem misleading.


>     # Meh: both the keyword and the variable name are used to indicate what
> the argument means. It's not really bad, but it adds no information while
> adding redundancy. This would happend if the keyword is required.
>     raise_errors=True
>     process(data, raise_errors=raise_errors)
>

That's actually fine with me; there's often a reason to give the variable
another name anyways.


>     # Bad: a variable name is used but it doesn't indicate anything on its
> meaning.
>     w=True
>     process(data, w)
>

All depends.

In any case the discussion was more about how to design the API in the
first place than about what the call should look like. In particular, if
the raise_errors parameter is nearly always given as the literal True or
False, it might be better to have

  process(data)

and

  process_raising_errors(data)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160510/f016cc57/attachment.html>


More information about the Python-ideas mailing list