"if" condition for boolean settings: == 1, == True or just omit?

Here is simple ST plugin. Is there a difference between commented lines? Personally, I don't see any difference in how they work, just a difference in visual appearance.

However, some plugin developers prefer second version (== 1), which looks just useless and ugly for me. Probably there are some reasons to prefer it?

import sublime_plugin

class ExpandUnexpandTabsCommand(sublime_plugin.EventListener):
    def on_pre_save(self, view):

        # if view.settings().get("translate_tabs_to_spaces"):
        # if view.settings().get("translate_tabs_to_spaces") == 1:
        # if view.settings().get("translate_tabs_to_spaces") == True:
            view.run_command("expand_tabs")
        else:
            view.run_command("unexpand_tabs")

if view.settings().get("translate_tabs_to_spaces") is more concise and readable. There is little if ever any need to compare a Boolean to another Boolean value, and using integers of 0 and 1 to denote a Boolean value should only be considered when the programming language does not support Boolean values.

Comments
  • It depends. What are the possible values in the settings files? In Python, if spam: is a test for whether spam is truthy. If spam has to be a number, and you want to test nonzero-ness, if spam: is fine; if you test if spam == 1:, you're saying you want it to fail on 2. If spam has to be a boolean, if spam: is good and if spam == 1: is terrible and misleading. If spam could be either None or some valid object, you want if spam is not None:; if spam: may seem to work, until [] or 0 is a valid object. And so on. Understand what you're writing, write what you mean.
  • This question is probably off-topic because it is likely to attract opinion-based answers. That said, since all values in Python have a boolean value, the == True looks really silly for me. The == 1 looks silly unless you are actually testing for the value being exactly 1. So IMO the idiomatic choice is to omit the == operator.
  • @PauloScardine == True has a specific idiomatic meaning: it's for the (very rare) case when you want the test to be true for the specific value of True, or for anything else which declares itself == True, but not for other truthy values like 17 or {1, 2, 3} or object(). If that's not what you mean, you shouldn't write == True. It's not just silly, it's actively misleading.
  • @abarnert How about is True?
  • @PauloScardine That's slightly less rare: you want the test to pass for True, but not for anything else, not even allowing for classes that declare themselves == True.
  • Well, if it is in PEP8 its officially idiomatic and not just my opinion. This is the right answer.
  • I can't se the case for if something == True. There is no difference at all to if something (well, there is the silly case where someone can override __eq__ to mask a is True test but I would write it off as a stinky code smell in Python).
  • @PauloScardine: Agreed. In very rare cases I might use is True; I'd never use == True unless I wasn't actually using it in a boolean context at all, e.g. where you expect == to be overridden to produce a special query object (part of an ORM like SQLAlchemy or the like, where a .filter(Table.some_column == True) makes some sense, though even then, I'd sort of hope the ORM knew how to handle boolean columns without requiring the use of == True).
  • @PauloScardine Examples I've seen (not counting ones that return an ORM query or NumPy bool array or the like) include an equals-everything object to affect stable sorting/tree-balancing/etc., and a proxy object that wanted to treat proxied TRUE (or whatever) as much like native True as possible. If you're expecting such a type, anywhere you would use is True (which is already rare at best), you'd want to use == True instead. It's rare enough, and weird enough, that I'd definitely double-check the type's docs or code first, but if that's what they intended, it's not silly, just weird.
  • Ok, I concede it is a tribute to the "we are all consenting adults" in Python but while it allows some DSL magic it is definitely is a code smell for more general code.