On Thu, Nov 12, 2009 at 8:10 PM, r <span dir="ltr"><<a href="mailto:rt8396@gmail.com">rt8396@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On Nov 12, 7:44 pm, Steven D'Aprano <st...@REMOVE-THIS-<br>
<a href="http://cybersource.com.au" target="_blank">cybersource.com.au</a>> wrote<br>
<div class="im">> Oh, but those hundreds of thousands of man-hours lost to bugs caused by<br>
> assignment-as-an-expression is nothing compared to the dozens of man-<br>
> minutes saved by having one fewer line of code!<br>
<br>
</div>OK, what *if* the variable would only be valid in *that* block and<br>
*that* block only! My first idea was to have the variable avaiable in<br>
the local scope (if that is correct terminology?) so if the<br>
conditional was in global space the value would be available in global<br>
space, alright? You follow me? Now forget all that and observe the<br>
following. ;-)<br>
<br></blockquote><div><br>Assignment is a statement and not an expression in Python intentionally; its not just some random artifact. It was a decision. If you really want to overcome it, you need to show a SERIOUSLY huge amount of justification that goes far beyond 'hey, it saves me one line in certain situations'. You keep mentioning "elegant" and "clean" in the examples you've provided, but those terms (while often applied to Pythonisms) are very subjective.<br>

<br>What you find elegant and clean, others may find prone to confusion or misunderstanding.<br><br>There's a certain class of languages which treat assignments as expressions-- the C family most prominently. And some people love them and will forever seek it, as there is indeed a reduction of lines and/or code to express certain ideas if you use assignments as expressions. No one is really arguing against that.<br>

<br>The argument against it is that it is extremely easy to screw up in ways which are extremely difficult to debug.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


if value=range(10):<br></blockquote><div><br>The problem with this is, its far too easy to type this but mean, "if value==range(10):" or some such.<br><br>And then its far too hard to figure out why your program is wrong when it starts producing incorrect results. This has been a source of countless bugs over the years and years of C programming-- true, an excellent programmer will never make the mistake. But get some group of people together maintaining some codebase, and someone's gonna miss something, and others just will fail to see it as they scan over the code trying to figure out what's wrong.<br>

<br>Granted, you can produce shorter and more concise code if you can make assignments expressions instead of statements. However, your code isn't anymore READABLE. And readability is more important then concise in Python, /on purpose/.<br>

<br>It's true that you can usually produce a program in far fewer lines of Python code then you can in certain other languages not to be named; but that isn't the overriding goal. That's not a zen. There's no doctrine of, "Shorter is better".<br>

<br>Readability counts is, though.<br><br>The expression, "x=y" in a statement is far too easy to mess up with "x==y". You can try to do screwy things with the syntax like your original proposal of, "if x as y" to make it so a single missed = won't mess it up, but that doesn't really improve readability. It makes it less likely to accidentally screw things up, but also makes it very hard to scan code and determine where names are created and assigned to objects.<br>

<br>Yeah, we use "as" in a few situations for assignment already. But those are all special constructs which stand on their own. Try/except, with, and import support it; but when scanning code those stand out on their own anyways, and none of them support arbitrarily complex expressions. The if statement does. The "as" can become lost within that expression, and when looking in the block of code you can easily miss where the binding occurs.<br>

<br>The proposal that the variable exists only within the 'if' block is a non-starter; Python's namespaces don't work like that, they don't have arbitrary blocks of private variables. You just have your local, global, and builtin namespace (and static nested namespaces for closures)... changing that is a whooooooooole other can of worms, and this is not the proposal to do it.<br>

<br>--S<br>
</div></div>