On 2019-12-21 4:52 p.m., Chris Angelico wrote:
On Sun, Dec 22, 2019 at 6:35 AM Soni L. <fakedme...@gmail.com> wrote:
>
>
>
> On 2019-12-21 4:15 p.m., Andrew Barnert wrote:
> > > On Dec 21, 2019, at 08:41, Soni L. <fakedme...@gmail.com> wrote:
> > >
> > > I'd like to see the ability to do:
> > >
> > > if x:
> > > 1
> > > and if y:
> > > 2
> > > or if z:
> > > 3
> > >
> > > The truth table for these would be:
> > >
> > > x | y | z | result
> > > 0 | _ | 0 | (none)
> > > 0 | _ | 1 | 3
> > > 1 | 0 | _ | 1,3
> > > 1 | 1 | _ | 1,2,3
> > >
> > > and each statement is evaluated once, when encountered. (as such, y and z
may not be evaluated at all, if their evaluation is not necessary to determine the
outcome.)
> >
> > So this is equivalent to:
> >
> > if x:
> > if y:
> > 1, 2, 3
> > else:
> > 1, 3
> > elif z:
> > 3
> >
> > I can see how the former saves me having to repeat the 3 three times. But
the cost is being less obvious about when exactly I get a 3 so I’m forced to work it
through step by step—including the confusion about the 1,0,0 case, which, as you
mentioned, is only clear if you imagine putting an else at the end (although maybe
you’d get used to that once you’d read through enough of these?). It’s even less
obvious if you do throw in an elif, or just add an and if to the end (so now the
condition to get there is not “x and y or z and w” but, I think, “((x and y) or z)
and w”?
> >
> > Does that advantage outweigh the disadvantage? Certainly not for this
example. But that’s probably because even the rewritten example is meaningless and
useless. Maybe it would be different with a realistic use case, but I can’t imagine
what that would be. Surely you must have some case where you really wanted this, that
motivated you to propose it?
> >
> >
> >
>
> "1" and "2" and "3" are pieces of code, ofc.
>
> it's actually more like:
>
> if flag := x:
> 1
> if y:
> 2
> if flag or z: # note that "or" is short-circuiting.
> 3
>
> but more efficiently implemented in bytecode without that "flag" local
> showing up.
>
> it's literally meant for easing the translation of switch statements
> from other languages and nothing else. (well, at least the "or if" part.
> the "and if" part isn't very useful. maybe to reduce deep indentation I
> guess?)
I'm not sure I understand what switch construct would translate into
this style. Can you show an example of code in some other language,
how you'd translate that same logic into today's Python, and how you'd
translate it into this "and if" / "or if" style?
(BTW, it's probably clearer to represent your blocks of code as
"spam()" and "ham()" rather than using numbers. I'm sure I wasn't the
only person who was confused by those.)
Lua's VM had a case that went like this:
switch (op) {
[...]
case OP_TAILCALL: {
adjust_regs();
some_other_stuff();
/* fallthrough */
}
case OP_CALL: {
make_the_call_happen();
break;
}
}
This is for what's known as "tail-call optimization". Anyway, if one
were to translate this with "or if", it would look like:
if op == OP_TAILCALL:
adjust_regs()
some_other_stuff()
or if op == OP_CALL:
make_the_call_happen()
Importantly, note how there's no need for a "break" statement, and the
fallthrough is explicitly stated in the use of an "or if" statement.
ChrisA
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ILB5GKJYH6JIAJ3Z65LVNGXWUTH3TILH/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/LE3U2ZTFME6VJ4WZJLEDFADAD7M56USV/
Code of Conduct: http://python.org/psf/codeofconduct/
