Comments on: Idiomatic Python refactoring: for-else, “in” (contains) operator

By: Christopher Leary

Christopher Leary — Sat, 21 Mar 2009 08:33:02 +0000

@rgz: Yeah, it's pretty neat that way, but it's only coincidental. It's important not to get too bogged down in reads-like-English-ness, or you end up with overly complicated things like Perl's natural language constructs (i.e. postfixed if/unless statements) or a strange emphasis on English-like readability, like in this COBOL example on Stack Overflow.

By: rgz

rgz — Sat, 21 Mar 2009 06:54:30 +0000

Holy cow! That not just Pythonic, it reads as ok English.
“If [there're] choices and value not in choices, raise BadValueError.”

By: Christopher Leary

Christopher Leary — Sat, 20 Dec 2008 02:12:44 +0000

@G: Agreed. If you read carefully you’ll see that the statement was unrelated to the usage of for-else:

“We also gain some efficiency over the original by using the break statement as soon as we find a match”

Thanks for pointing it out more explicitly, though!

By: G

Sat, 13 Dec 2008 14:07:53 +0000

The note about the forelse being more efficient over break is moot. You could of used break in the first code too

By: Christopher Leary

Christopher Leary — Mon, 06 Oct 2008 00:09:21 +0000

@Dave Kirby: value in [] is always False, since an empty list contains no values. Thus, value not in [] is always True. Therefore, your snippet will raise a BadValueError if choices evaluates to False, whereas the original snippet will bypass the check altogether if choices evaluates to False.

By: Dave Kirby

Dave Kirby — Sun, 05 Oct 2008 16:40:52 +0000

how about:

if  value not in (choices or []):
    raise BadValueError

If choices is None/False/0 etc then (choices or []) will evaluate to an empty list. The expression needs to be in brackets since ‘in’ binds more tightly than ‘or’.

Admin: Fixed code syntax — correct markup is “pre lang=’python’”.

By: Christopher Leary

Christopher Leary — Sun, 05 Oct 2008 05:46:06 +0000

@David: In the original code, if choices is anything that evaluates to False, the lookup isn’t performed. For example, the lookup would have been bypassed if choices were False, None, or even an empty iterable! If choices were None, your snippet would have raised a TypeError, which doesn’t follow the semantics of the original.

You could do something like:

try:
    if value not in choices:
        raise BadValueError
except TypeError: # Non-iterables.
    pass

But this also changes the behavior from the original in a subtle way. Empty iterables (like []) will raise a BadValueError here, but would have evaluated to False in the original “if choices” and bypassed the value check altogether.

By: David Buxton

David Buxton — Sat, 04 Oct 2008 23:57:12 +0000

Why does one need to test for choices as well as value not in choices? Wouldn’t

if value not in choices:
raise BadValueError

be sufficient? Or is choices set to a non-iterable when it is empty?

By: Steven

Steven — Fri, 03 Oct 2008 17:20:55 +0000

Nice refactoring :)

I think the original snippet of code comes from the C/C++ mentality (e.g. those who first started programming in C). I still find myself writing code like that, even after being exposed to all kinds of syntactic goodies, because it’s the first thing that comes to mind…

Nice tip on for..else as well, I’ve never used it before but maybe I’ll give it a try now :)