5 ms·

if var: ... is better code (for my value of better, which is subjective) than: if var is not None: ...

• batmansbelt 13y ago
  By what criteria have you decided that?
  • tehwalrus 13y ago
    quicker to scan-read ("code will be read many more times than it is written or modified", being the relevant axiom)
    • Iftheshoefits 13y ago
      Reading code is a purposeful activity, though; namely, to understand what the code does. The speed with which that can be done is relevant in the margins from a productivity standpoint, but to build an argument for code structure around it strikes me as missing the point of the "axiom" you quote.
• mildtrepidation 13y ago
  In my opinion, the "explicit is better than implicit" mantra of Python (which I find very sensible) should immediately imply preference for the second, even in cases where the first is almost certainly not going to cause problems. Testing for "not None" also immediately tells other devs at least something about what's going on. Example: If var is an argument to a function and you see "if var," really understanding what's going on means looking at all invocations of that function to see what's being passed in. Further, in that scenario, it's possible that different types are being passed for that argument. While "if var" could make this work where "if var is not None" would break functionality, in my opinion, it should break. Without getting into arguments about static typing, "truthiness" allows both sloppy code and the accidental introduction of bugs that might otherwise be caught during development due to faulty logic from vague conditional checks.
  • maxerickson 13y ago
    It's a rule of thumb, not a mantra. I suppose the hilarious way to argue it would be to say that there is an implicit "all other things being equal" in front of each of those.
    • mildtrepidation 13y ago
      Call it what you want; I'm not arguing it to be pedantic, I think it's a very practical approach. But if you prefer: All other things being equal, I see no reason to write code that needlessly introduces potential bugs and maintainability issues by ignoring the rule of thumb that explicit trumps implicit.
      • maxerickson 13y ago
        It's an old argument. I don't have real strong feelings about it. I think there is enough code doing one or the other out there that the end result is to understand well the ramifications of both, so it ends up a matter of taste. The documentation is pretty clear about it: http://docs.python.org/release/3.3.4/library/stdtypes.html#truth-value-testing http://docs.python.org/release/3.3.4/library/stdtypes.html#t... Which leads to this: >>> a=object() >>> bool(a) True >>>
  • pyre 13y ago
    So since we need to be explicit, it should be: if var in (None, 0, "", [], {}, ...): pass something like that? In general, most of those false-y values make sense. Midnight being a false-y value does not make sense. This seems to be a case of "we represent midnight as zero internally, and zero is false-y, so midnight should be false-y." This logic does not make sense to me. If they represented noon as 0 instead, should that evaluate to false, just because?
    • mildtrepidation 13y ago
      If you need to use a test like that, you've already gone too far down the road of lazy "falsey" value usage, and whoever wrote it didn't bother with the idea of sensible defaults or consistent typing/initialization. I agree that midnight evaluating to false is ridiculous (I wasn't aware of this, thankfully I've never run into it). I'm not sure where you got the idea that I support this, but I don't.
• Cowen 13y ago
  I prefer the second one. Explicit is better than implicit.
  • windsurfer 13y ago
    The second what?
    • Spiritus 13y ago
      The second example: if var is not None: ...
      • windsurfer 13y ago
        I was making a joke about being explicit versus implicit ;)
  • pyre 13y ago
    If explicit is always better than implicit, why is Python dynamically typed?
    • lmm 13y ago
      Because at the time it was originally written, it seemed impossible to write a statically typed language that was beautiful, or even readable. This has now proven to be false, and python is starting to add optional type annotations. It's not practical to introduce static typing more quickly - it would break too many existing programs.
  • yxhuvud 13y ago
    So why is it better to have to check for None but not having to check for midnight? The latter seems a lot less common and surprising.
• dagw 13y ago
  They do two entirely different things in python. Occasionally you might actually want the functionality of the first statement, but if you write the first statement and expect it to do the same as the second statement, then that is a bug in your code. You could argue that the python is badly designed in this case and that the two should be equivalent, but that's a different argument.
• jofer 13y ago
  Not in python. if var: ... is better in some situations, but is objectively worse in many others. If you really do want anything that's "falsey" to fall into that conditional, then by all means, use it! Just be aware that `0`, `[]`, `None`, `0.0`, etc will all be treated the same. However, it's harmful in one of its most common use cases: default values. For example, let's say you're working with a function that takes an optional argument similar to: def foo(x, values=None): if values is None: values = [] You shouldn't use a mutable default argument for several reasons, so instead you make the default "None" and set it to an empty sequence. The snippet above is the standard idiom. Let's say a user mistakenly passes "values=0" instead of "values=[0]". If you had done: if not values: values = [] Then the code will happily proceed with "values" being an empty list and _silently give incorrect output_ instead of raising an error a couple of lines later. You can make the (very reasonable) argument that this is all the fault of dynamic typing, and if python was just a staticly typed language, the compiler would catch all of this, but that's beside the point. Be aware of what you're testing if you choose "if var:" instead of "if var is not None:"
  • tehwalrus 13y ago
    default values is a special case (and one which I consider to be a bug in python, frankly, since it bites everyone who didn't read up on default arguments before the wrote some code - everyone uses [] as a default argument at some point and then spends an amount of time proportional to the complexity of their program debugging the insane behaviour before noticing. My program was quite long and complex, and I am still bitter.) I didn't argue, and certainly didn't mean to imply, that it is always better, but in the sort of case we're considering in this example, i.e. we expect a valid time value or None, It really is madness to imply a time value of midnight is "empty".
  • couchand 13y ago
    Nice job explaining away one language bug with another.
• keypusher 13y ago
  One of the core tenets of Python is that "explicit is better than implicit". So why is your way better than an explicit check?
• mcherm 13y ago
  That is a rather silly statement since the two do not have the same behavior. So it is not a subjective question: one is right and the other is wrong. (For certain types, they do have the same behavior. In those cases, the subjective question is fine. But times are not a case where the behavior is the same.)
• jemfinch 13y ago
  "Also, beware of writing if x when you really mean if x is not None -- e.g. when testing whether a variable or argument that defaults to None was set to some other value. The other value might have a type (such as a container) that could be false in a boolean context!" From PEP-8: http://legacy.python.org/dev/peps/pep-0008/ http://legacy.python.org/dev/peps/pep-0008/