<p dir="ltr"><br>
On 8 Jun 2015 11:07, "Cory Beutler" <<a href="mailto:cgbeutler@gmail.com">cgbeutler@gmail.com</a>> wrote:<br>
><br>
> Thank you all for your responses. I didn't realize how much support this mailing list had.<br>
><br>
> In response to several responses:<br>
><br>
> 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. </p>
<p dir="ltr">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.</p>
<p dir="ltr">The exception handler case is the odd one out, since that includes an implied "del" whenever execution leaves the cobtained suite.</p>
<p dir="ltr">Any form of inline assignment that doesn't use "as NAME" will need a good justification.</p>
<p dir="ltr">(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)</p>
<p dir="ltr">> 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.</p>
<p dir="ltr">Commas are generally out, due to the ambiguity with tuple construction.</p>
<p dir="ltr">> 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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>