On Tue, May 10, 2016 at 4:59 PM, Joseph Martinot-Lagarde <contrebasse@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)