Sorry, early send... Sent from my iPhone
On Jun 7, 2015, at 21:24, Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
On Jun 7, 2015, at 20:41, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 8 June 2015 at 12:45, Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Jun 8, 2015 at 12:33 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote: I'm definitely -1 on the also, alif syntax at this point. On the other hand, having done a lot of C programming in my misspent youth, I do miss anaphoric conditionals, so I too would like to see the possibility of "if cond as var: do_something_with_var" explored. Of course Nick is right that automatic common subexpression elimination (CSE) is the big win, but manual CSE can improve readability.
Part of the trouble with depending on CSE is that Python is so dynamic that you can't depend on things having no side effects... but the more important part, in my opinion, is that duplication is a source code maintenance problem.
Yes, this is the part of the problem definition I agree with, which is why I think named subexpressions are the most attractive alternative presented in the past discussions.
The problem with general named subexpressions is that it inherently means a side effect buried in the middle of an expression. While it's not _impossible_ to do that in Python today (e.g., you can always call a mutating method in a comprehension's if clause or in the third argument to a function), but it's not common or idiomatic.
You could say this is a consulting-adults issue and you shouldn't use it in cases where it's not deep inside an expression--but those are the actual motivating cases, the ones where just "pull it out into a named assignment" won't work. In fact, one of our three examples is:
[b for a in iterable if (a.b as b)]
That's exactly the kind of place that you'd call non-idiomatic with a mutating method call, so why is a binding not even worse?
Maybe something more like a let expression, where the binding goes as far left as possible instead of as far right would look better,
... but I can't even begin to think of a way to fit that into Python's syntax that isn't horribly ugly and clunky, and "as" already has lots of precedent, so I think that's not worth exploring.