New syntax for blocks
bdesth.quelquechose at free.quelquepart.fr
Fri Nov 13 21:53:27 CET 2009
r a écrit :
> On Nov 12, 7:44 pm, Steven D'Aprano <st... at 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!!!
> elif value=fetch(0):
> #this block would *never* execute
> value.append(1) -> this throws a NameError
> Is that different than how other languages handle "assignment-by-
> expression"? Will that avoid the cataclysmic downward spiral you speak
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.
More information about the Python-list