[Python-ideas] If branch merging

[Nick Coghlan]

On 8 Jun 2015 11:07, "Cory Beutler" <cgbeutler at gmail.com> wrote:
>
> Thank you all for your responses. I didn't realize how much support this
mailing list had.
>
> In response to several responses:
>
> It appears I have hit a soft spot with the 'as' keyword. It seems clear
to me that inlining an assignment confuses scope. With any inline solution,
that confusion will exist.

Not really, as we have a number of inline assignment and renaming
constructs, and they all use "as" (import, with statements, exception
handlers). For loops, function definitions and class definitions also help
establish the behaviour of name bindings in compound statement header lines
affecting the containing scope rather than only affecting the internal
suite.

The exception handler case is the odd one out, since that includes an
implied "del" whenever execution leaves the cobtained suite.

Any form of inline assignment that doesn't use "as NAME" will need a good
justification.

(It's also worth noting that "as" clauses are specifically for binding to a
name, while the LHS of an assignment statement allows attributes, indexing,
slicing and tuple unpacking)

> Avoiding absentminded mistakes is always good to do. There are many other
possible solutions from a comma, as in "if a == b, aisb:", to a custom
language addition of a new keyword or operator.

Commas are generally out, due to the ambiguity with tuple construction.

> Irregardless of how inline assignment is written, the scope issue will
still exist. As such, it is more important to decide if it is needed first.
The fact that this idea has been brought up before means that it deserves
some research. Perhaps I can do some analytics and return with more info on
where it could be used and if it will actually provide any speed benefits.

In this particular case, the variant that has always seemed most attractive
to me in past discussions is a general purpose "named subexpression"
construct that's just a normal local name binding operation affecting
whatever namespace the expression is executed in.

In the simple if statement case, it wouldn't be much different from having
a separate assignment statement before the if statement, but in a while
loop it would be executed on each iteration, in an elif it could make the
results of subcalculations available to subsequent elif clauses without
additional nesting, and in the conditional expression and comprehension
cases it could make part of the condition calculation available to the
result calculation.

It would certainly be possible for folks to go overboard with such a
construct and jam way too much into a single expression for it to be
readable, but that's already the case today, and the way to handle it would
remain the same: refactoring the relevant code to make it easier for
readers to follow and hence maintain.

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150608/cd584911/attachment.html>