New syntax for blocks

[Bruno Desthuilliers]

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!!!
>     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.