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!
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.
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.
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.,
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))
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))
