[Python-ideas] If branch merging

[Cory Beutler]

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. Now, I will say that I do not like 'if aisb = a
== b' because of the potential errors, as others have mentioned. A language
should be written as much for the beginners as the experts, or it will
never live very long. 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.
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.

Ok, that was a bit of a shotgun response to many remarks. Hopefully it will
suffice. Thanks again for all the feedback.

I would now like to respond to Steven's response directly:

On Sat, Jun 6, 2015 at 11:19 PM, Steven D'Aprano <steve at pearwood.info>
wrote:

> On Sat, Jun 06, 2015 at 09:03:38PM -0600, Cory Beutler wrote:
>
> [...]
> > This would simplify some logic expressions by allowing the merging of
> > branched code.
> >
> > *Examples of use:*
> > *Duplicate code in if-chains may be reduced:*
> > # Old Version
> > if a == b:
> >     print ('a == b')
> >     foo()             # <-- duplicate code
> > elif b == c:
> >     print ('b == c')
> >     foo()             # <-- duplicate code
> > elif c == d:
> >     print ('c == d')
> >     foo()             # <-- duplicate code
>
> if a == b:
>     print('a == b')
> elif b == c:
>     print('b == c')
> elif c == d:
>     print('c == d')
> foo()
>
> No new syntax required.
>
>
The functionally is not the same. In your example 'foo' gets called even if
none of the conditions are true. The above example only runs 'foo' if it
enters one of the if-blocks.
This basic layout is useful for various parsing and reading operations. It
is nice to check if something fits various conditions, then after the
specific handling, add on finishing details in a 'foo'-like context.


>
> > *Many nested 'if' statements could now be a more linear style:*
> > # Old Version
> > if a == b:
> >     print ('a == b')
> >     if b == c:
> >         print ('b == c')
> >     print ('end if')
>
> What's wrong with that code? Nesting the code like that follows the
> logic of the code: the b==c test *only* occurs if a==b.
>
>
> > # New Version
> > if a == b:
> >     print ('a == b')
> > alif b == c:
> >     print ('b == c')
> > also:
> >     print ('end if')
>
> I consider this significantly worse. It isn't clear that the comparison
> between b and c is only made if a == b, otherwise it is entirely
> skipped.
>
>
It may only be worse because you are not used to reading it. This type of
syntax looks simple once you know how the pieces work. I mean, you know
that having multiple if-elif statements will result in only checking
conditions until one passes. The 'also' mentality would be the same, but
backwards.

> *Selective Branch merging:*
> > One limitation of the 'also' and 'alif' keywords is the restriction to
> the
> > "all of the above" checking. What I mean by that is that there is no way
> to
> > pick and choose which branches to merge back together. When using 'also'
> > and 'alif' you are catching all previous if-branches. One easy way to
> solve
> > this would be to allow for named branching. The most simple way to do
> this
> > is to save the conditions of each branch into a variable with a name.
> Here
> > is an example of merging only select branches together:
> > # Old Version
> > if a == b:
> >     print ('a == b')
> > elif a == c:
> >     print ('a == c')
> > elif a == d:
> >     print ('a == d')
> > if (a == b) or (a == d):
> >     print ('a == b and a == d')
>
> That code is wrong. Was that an intentional error? The final branch
> prints that a == b == d, but that's not correct, it runs when either
> a == b or a == d, not just when both are true.
>

Yeah, that was a mistype. That is why I shouldn't program fake code late at
night. It does warm my heart to see that 2 people have corrected my fake
code. That means it is easy to learn and understand.


>
> Personally, I would write that as:
>
> if a == b or a == d:
>     if a == b:
>         print('a == b')
>     else:
>         print('a == d')
>     print('a == b or a == d')
> elif a == c:
>     print('a == c')
>
> You do end up comparing a and b for equality twice, but worrying about
> that is likely to be premature optimization. It isn't worth adding
> syntax to the language just for the one time in a million that actually
> matters.
>
>
With that rearrangement, you could write it with 'also':
if a == b:
    print('a == b')
elif a == d:
    print('a == d')
also:
    print('a == b or a == d')
elif a == c:
    print('a == c')

but that does not demonstrate the selective branch merging. It would not
work so well to combine the next two 'elif' statements, as any other 'also'
blocks would capture the 'a == b', 'a == d', and first 'also' branches. I
guess what I mean to say is that this example is a little too dumbed down.
I think you know what I am after, though. If 'a == b' is a heavy duty
calculation, it would be nice to be able to store that inline.

Thank you, Steven, for your objective view of things. It is has been useful
to see an outside perspective. I look forward to your future input.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150607/410755b4/attachment.html>