PEP-308 a "simplicity-first" alternative

[holger krekel]

Christian Tismer wrote:
> holger krekel wrote:
> > Andrew Koenig wrote:
> > 
> >>holger> Inspired by "do the simplest thing that can possibly work" i
> >>holger> now think that
> >>
> >>holger>         x and y else z
> >>
> >>holger> might just do it and avoid the need for a new construct.  
> >>
> >>I thought so too when I first saw it, but now I'm less sure.
> >>For example, what is the meaning of
> > 
> > Damn, you get to the point where i was too lazy to think it out :-)
> > 
> >>        w and x and y else z
> >
> >         (w and x) and y else z
> > 
> > should be the meaning. 
> 
> Wrong.
>            w and (x and y else z)

In fact, i don't care too much either way.  The main requirement
is that precedence and grouping rules need to be consistent. 

But i think i'd like 

    obj and obj.method() and "yes" else "no"

to return "no" instead of AttributeError on None :-)

> [...]
> > Or in Grammar speek:
> > 
> >     and_test: not_test ('and' not_test ['else' not_test])*
> 
> I don't have the grammar, yet.
> But this one doesn't do what I mean.

I think it would work for your case.  You need to sort it out in
the compiler with some look-ahead. This is because when seeing

    w and x and y else z
    ^^^^^^^

the first part you don't know that 'x' in fact belongs to a ternary. 
If you try to code it into the parser you might again need look-ahead
which does not work there.  That's why i thought it's better to just 
recognize the "and y else z" part and not care about what came earlier.  

chaining ternary operators without parens is 
a-bit-insane-anyway-ly y'rs,

    holger