Nick Coghlan wrote: > Andrey Tatarinov wrote: > > Hi. > > > > It would be great to be able to reverse usage/definition parts in > > haskell-way with "where" keyword. Since Python 3 would miss lambda, that > > would be extremly useful for creating readable sources. > > > > Usage could be something like: > > > > >>> res = [ f(i) for i in objects ] where: > > >>> def f(x): > > >>> #do something > [snip] > For compound statements, a where clause probably isn't appropriate, as it would > be rather unclear what the where clause applied to.
Right. But you know that as soon as you add this to simple expressions, a bunch of people are going to come here whining about how they don't get to use where with if-expressions. Frankly, they might have a point here. Although we have replacing lambda expressions on our minds, I have in mind a different problem that a where-statement would solve perfectly. But it would have to be used with an if-expression. However, I think it might not be so hard. Let's take Paul Rubin's advice and precede the if statement with where. Let's also allow "elif" clauses to be replaced with "else where ... if" clauses. That which is bound in the while-block would be visible in both the if-expression and if-block. Then we could do this: . where: . m = someregexp.match(somestring) . if m: . blah blah blah . else where: . m = someotherregexp.match(somestring) . if m: . blah blah blah We might want to spell "else where" instead as "elwhere", to match "elif", but that's not important now. This would take away one of the major minor annoyances of Python. (In fact, I've suggested something like this as a solution to the set-and-test idiom, which Python makes difficult, only I used the keyword "suppose" instead of "where".) Ok, but if you do that, now you have people whining that "where" comes after some expressions, and before others. (This would not bother me one bit, BTW, but I'm pretty sure I'd lose the popular vote on this one.) So, let's go all out and say that while could precede any statement. We now have consistency. Well, that really wouldn't work for the if-statement, though, because then how could we apply a different while-block to an else clause? We'd have to treat if-statements specially anyways. So we don't have consistency. My solution would be to propose two different where statements: a where...do statement, and a separate where...if statement. The where...do statement would look like this: . where: . def whatever(): pass . do: . blah blah use whatever blah It has the advantage of being able to apply the where bindings to several statements, and is, IMO, much cleaner looking than simply applying where's bindings to the single following unindented statement. I would recommend against where...while and where...for statements. They can't accomplish anything you couldn't do with a break statement inside the block, and it's not obvious whether the where clause gets executed once or for each loop (since it's physically outside the loop part). One question: what do you do with a variable bound inside a while-block that has the same name as a local variable? (Or, horrors, a surrounding while-block?) I'm inclined to think it should be illegal, but maybe it would be too restrictive. Anyways, I like this idea a lot. +1 -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
