On Thu, Apr 24, 2014 at 10:18 AM, Chris Withers <ch...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com