5 ms·

I'm skeptical about the last one return None

• Walkman 13y ago
  I saw this code yesterday: def is_file_for(is_nagyker, type): if type == KIS_ES_NAGYKER: return True elif type == KISKER and not is_nagyker: return True elif type == NAGYKER and is_nagyker: return True At the first glance, I thought it always return True. Would have been more clear an explicit return False at the end!
  • famousactress 13y ago
    Seems rude to return None instead of False for an is_. I think I would have written: def is_file_for(is_nagyker, type): return type == KIS_ES_NAGYKER or \ (type == KISKER and not is_nagyker) or \ (type == NAGYKER and is_nagyker)
    • MereInterest 13y ago
      As another change, it is recommended to avoid explicit line continuations by using parentheses instead. def is_file_for(is_nagyker, type): return ((type == KIS_ES_NAGYKER) or (type == KISKER and not is_nagyker) or (type == NAGYKER and is_nagyker)) This way, it doesn't break if there is extra whitespace at the end of the line.
      • famousactress 13y ago
        Thanks! I've wondered about this.. I do like the parens better, and it looks like PEP-8 agrees with you: http://legacy.python.org/dev/peps/pep-0008/#maximum-line-length http://legacy.python.org/dev/peps/pep-0008/#maximum-line-len...
      • meowface 13y ago
        As yet another change, PEP8 recommends placing comparison operators (and dots, when method chaining) at the beginning of each line to make things a little clearer. def is_file_for(is_nagyker, type): return ((type == KIS_ES_NAGYKER) or (type == KISKER and not is_nagyker) or (type == NAGYKER and is_nagyker))
        • RogerL 13y ago
          See, I don't find that clearer; quite the reverse. With trailing 'or' the type variable is nicely lined up, and the pattern matching that is going on is a lot clearer to my eye. With things misaligned, I have to much more carefully parse the text to see what is going on. I sometimes even do something like this (probably overkill in this example, but my aim is to illustrate a concept, not to bicker about the best expression of that particular statement): return ( (type == KIS_ES_NAGYKER ) or (type == KISKER and not is_nagyker) or (type == NAGYKER and is_nagyker))
          • abecedarius 13y ago
            def is_file_for(is_nagyker, type): return ( (type == KIS_ES_NAGYKER) or (type == KISKER and not is_nagyker) or (type == NAGYKER and is_nagyker))
            • meowface 13y ago
              Or maybe def is_file_for(is_nagyker, type): return ( (type == KIS_ES_NAGYKER) or (type == KISKER and not is_nagyker) or (type == NAGYKER and is_nagyker) )
          • meowface 13y ago
            Yours is more aesthetically pleasing, but being able to see the "or" quickly helps one understand the nature of the full conditional at first glance. The other reply to you seems to be the best of both worlds.
  • edavis 13y ago
    May I suggest `any` here? def is_file_for(is_nagyker, type): return any([ type == KIS_ES_NAGYKER, type == KISKER and not is_nagyker, type == NAGYKER and is_nagyker]) I know unsolicited code improvements from strangers isn't the coolest thing in the world, but `any` (and `all`) can really improve clarity for stuff like this. I know I use them quite a bit.
    • aidos 13y ago
      I saw that used in the article too - not something I'd thought to do myself. Thanks for pointing it out, I find it really readable and I know there are places I could use this.
    • shoyer 13y ago
      You create a list, so this expression won't shortcut like or. Or is definitely the right way to write an expression like this. Any has its place, but mostly when it's input is a generator, e.g., any(k in obj for k in other)
• famousactress 13y ago
  Me too. As blasphemous as it is, the "Explicit versus implicit" edict ends up used as defense for a lot of stuff that I consider pretty severely pedantic...