Cory Beutler writes:
It may only be worse because you are not used to reading it. This type of syntax looks simple once you know how the pieces work. I mean, you know that having multiple if-elif statements will result in only checking conditions until one passes. The 'also' mentality would be the same, but backwards.
And that inversion is what underlies Steven's point, I think. I see your point, *but only if 'elif' goes away*. Currently the "hangindent" formatting of if ... elif ... else signals a series of alternatives, as similar formatting does (as a convention, rather than syntax) in many other languages. This makes scanning either actions or conditions fairly easy; you don't have to actually read the "elif"s to understand the alternative structure. With also and alif, you now have to not only read the keywords, you have to parse the code to determine what conditions are actually in force. This is definitely a readability minus, a big one. It doesn't help that "else" and "also" and "elif" and "alif" are rather visually confusable pairs, but at this point that's a bikeshed painting issue (except that as proponent you might want to paint it a different color for presentation). There's also the "dangling also" issue: I would suppose that also has all the problems of "dangling else", and some new ones besides. For example, since "elif" really is "else if" (not a C-like "case"), it's easy to imagine situations where you'd like to have one also or alif for the first three cases, and one for the next two, etc. Python, being a language for grownups, could always add a convention that you should generally only use also and alif at the end of an if ... elif ... else series or something like that, but I think that would seriously impair the usefulness of these constructs. I'm definitely -1 on the also, alif syntax at this point. On the other hand, having done a lot of C programming in my misspent youth, I do miss anaphoric conditionals, so I too would like to see the possibility of "if cond as var: do_something_with_var" explored. Of course Nick is right that automatic common subexpression elimination (CSE) is the big win, but manual CSE can improve readability.