r a écrit : > On Nov 12, 7:44 pm, Steven D'Aprano <st...@remove-this- > cybersource.com.au> wrote >> Oh, but those hundreds of thousands of man-hours lost to bugs caused by >> assignment-as-an-expression is nothing compared to the dozens of man- >> minutes saved by having one fewer line of code! > > OK, what *if* the variable would only be valid in *that* block and > *that* block only!
Python doesn't have the notion of a "block scope" (or "block namespace"). > My first idea was to have the variable avaiable in > the local scope (if that is correct terminology?) so if the > conditional was in global space the value would be available in global > space, alright? You follow me? Now forget all that and observe the > following. ;-) > > if value=range(10): > #this block *would* execute and "value" would be a valid name > #but only IN this block!!! > value.append(1) > elif value=fetch(0): > #this block would *never* execute > value.append(1) > > value.append(1) -> this throws a NameError Yuck. > > Is that different than how other languages handle "assignment-by- > expression"? Will that avoid the cataclysmic downward spiral you speak > of? It's different, but only worse. It doesn't solve the problem of mystyping "=" instead of "==" - which is the reason why Python's assignement is not an expression, and it's not even consistent with mainstream languages that support "assignement as an expression". > I can't see any problems with it I do see at least two big ones !-) Now I don't mean there's not a use case for some "assign and test" syntax - Carl provided a good one, and indeed there are some cases where a dispatcher is *not* the simplest and obvious solution. But by all means, not *this* syntax. -- http://mail.python.org/mailman/listinfo/python-list
