New syntax for blocks

[Stephen Hansen]

On Thu, Nov 12, 2009 at 8:10 PM, r <rt8396 at gmail.com> wrote:

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

What you find elegant and clean, others may find prone to confusion or
misunderstanding.

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.

The argument against it is that it is extremely easy to screw up in ways
which are extremely difficult to debug.


> if value=range(10):
>

The problem with this is, its far too easy to type this but mean, "if
value==range(10):" or some such.

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.

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

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

Readability counts is, though.

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.

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.

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.

--S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20091112/071a8817/attachment-0001.html>