[Walkman]

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!

[edavis]

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]

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]

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]

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]

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.

[meowface]

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]

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))

[meowface]

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.

[abecedarius]

    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]

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)
                )

[zenbot]

This is incorrect. “The preferred place to break around a binary operator is after the operator, not before it.”

[meowface]

You're right. It must've been another Python style guide I somehow remembered that from.

From what I can tell this is kind of a point of contention among many developers; there are lots of debates when Googling that particular line.

[famousactress]

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-len...