For review: PEP 308 - If-then-else expression

[Peter Hansen]

Erik Max Francis wrote:
> 
> Peter Hansen wrote:
> 
> > Gerrit Holl wrote:
> >
> > > Guido van Rossum schreef op vrijdag  7 februari om 18:16:27 +0000:
> > >
> > > >         x if C else y if D else z <==> x if C else (y if D else z)
> > >
> > > Doesn't this equal ((z ,y)[bool(D)], x)[bool(C)]? I think it's
> > > good enough.
> >
> > If I saw *either* of those in real code produced by someone in my
> > group,
> > the code would immediately be rewritten.  Neither is readable.
> 
> By the way, the same is true in C or C++ with the normal ternary
> operator.  Once you start chaining them together they get really ugly,
> really fast.  That's just pilot error (writing code which is hard to
> read), not a flaw in the construct itself.

I hadn't thought of C, but I wonder if you're really correct.  I learned
to make such things fairly readable, even when complex, with appropriat
indentation:

  a =   (expr1)
      ? (cond1)
      :   (expr2)
        ? (cond2)
        :   (expr3)
          ? and so on...

(It looks more readable in real code than it does above, although don't
get me wrong: I'm not saying it's _really_ readable, just not bad.)

So my question is, does the new construct lend itself to such formatting
(always assuming you surround the mess with parentheses to let it spread
across multiple lines nicely)?  Just curious whether the strange inversion
of expr/condt/condf to condt/expr/condf actually works against this type
of "readability assist".

-Peter