[Python-Dev] pep8 reasoning

[Tal Einat]

On Thu, Apr 24, 2014 at 10:18 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> A couple of others that have raised some consternation; what are the
> technical reasons for this pattern being bad:
>
> if len(seq)
> if not len(seq)
>
> ...or, for me, the rather ugly:
>
> if 0 != len(seq)
>
> Likewise, these:
>
> if greeting == True:
> if greeting is True:

As far as I know that reason for these examples being frowned upon is
that they are needlessly redundant. This is not just a matter of
minimalism or style; it's a matter of readability.

If you're relying on the "len()" call to fail if "seq" isn't a
container (for example, if it's None), the code for that should be
separate and more explicit.

Regarding "if something == True", that's only the same as "if
greeting" if greeting is assumed to be a boolean value. If so, it is
better (for readability) to use a descriptive variable name: "if
should_greet:". Otherwise (e.g. if greeting could also be None) it is
reasonable to check if it is equal to a specific value (with a short
comment explaining this point!).

Also, there's no end to how much comparison to True one can do:

if (greeting == True) == True
if ((greeting == True) == True) == True

Considering that, IMO it makes sense to just avoid such comparisons altogether.

- Tal Einat