[Python-ideas] If branch merging

Andrew Barnert abarnert at yahoo.com
Mon Jun 8 06:27:05 CEST 2015

Sorry, early send...

Sent from my iPhone

> On Jun 7, 2015, at 21:24, Andrew Barnert via Python-ideas <python-ideas at python.org> wrote:
>> On Jun 7, 2015, at 20:41, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> On 8 June 2015 at 12:45, Chris Angelico <rosuav at gmail.com> wrote:
>>>> On Mon, Jun 8, 2015 at 12:33 PM, Stephen J. Turnbull <stephen at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150607/5197d4c0/attachment.html>

More information about the Python-ideas mailing list