attaching names to subexpressions

[rusi]

On Oct 28, 5:49 am, Steven D'Aprano <steve
+comp.lang.pyt... at pearwood.info> wrote:

> It's sure as hell more beautiful and readable than assignment as an
> expression.
>
> If we are going to judge code on the ability of people to take a quick
> glance and immediately understand it, then pretty much nothing but
> trivial one-liners will pass. Certainly assignment as an expression won't:
>
> while (look_ahead(it) and next(it) or default).strip().lower() as line:
>     spam(x)
>
> is easy to miss that it is an assignment to x. *Much* easier than missing
> an indented "break".
>
> > In
> > my opinion I shouldn't be obliged to read any of the indented lines of
> > the while statement on a first 'visual' pass through somebody elses code
> > and still be able to see what the loop iterates through.
>
> Fine. Then write your code as:
>
> line = function(x, y, z)
> while line:
>      do something with(line)
>      line = function(x, y, z)
>
> > Following looks in my opinion nicer.
>
> > while complex_expression as line:
> >      do_something_with(line)
>
> That's only because you don't actually have a complex expression. Just
> writing "complex_expression" doesn't make it complex -- it's actually
> trivially simple, a mere rebinding of a name to a name, no more "complex"
> than
>
> while x as y:
>     ...
>
> See how easy to read it is! Well duh. But write out an *actual* complex
> expression, and the "as name" can easily disappear into the noise.
>
> Complex expressions are a code smell at least as bad as violating DRY,
> and frequently much worse. If the expression is too complex to write
> twice, refactor it into a function, *and write tests for the function*.
> Otherwise that complex expression is a bug waiting to bite, whether you
> write it once or twice.

The details of the various syntaxes proposed Ive not fully gone into
and I am not discussing.
The general notion of having assignments inside expressions would put
python into the C bracket
I had written about the 'all-hell-breaks-loose' when using C to teach
programming:
http://www.the-magus.in/Publications/chor.pdf

That paper is dated... if C is dated.  Otherwise I would request
people having this idea to read it.

In particular, with respect to this suggestion, heres how things tend
to pan out when the language allows assignments inside expressions:
You cant really *teach* students to use
i=i+1;
instead of
i++;
because its unidiomatic C.

And then someone (with no malice just ignorance) writes:
i=i++;
What does the teacher do? You can simply say: "Dont do that!!" and
confuse the students with what exactly is the set of "Dont-dos" (or
worse leave them smug that they understand when they dont)

Or you can explain why it could increment i or leave it unchanged and
so is indeterminate.

So I would take the 'muscular' approach -- Show expressions like:
i=i++-1;
1. Explain why it could increment, decrement or leave i unchanged
2. Elaborate compilation strategies for each of the above
3. Work out sufficient conditions for the behavior of an expression to
be determinate, viz. Variables that are assigned inside an expression,
should have only a single occurence, multiply occurring variables
should not be assigned. [And assignment means all forms: = += ++ etc)

Naturally when students are taught like this, they tend to become
cowboys -- learning all kinds of tricks of a narrow and useless sort
and ignoring more important aspects of their studies.  And if python
chooses such a direction its sad (for us teachers)

Having said this I need to add: the imperatives of teaching and
professional development are not the same.  If professional developers
feel that adding confusing semantics for the sake of saving lines of
code is a benediction... Well...