PEP308: Yet another syntax proposal

[holger krekel]

Dave Brueck wrote:
> On Mon, 10 Feb 2003, holger krekel wrote:
> 
> > > > > z = iif(x, x.getPref(), 'Not specified')
> > > > >
> > > > > is broken without short-circuiting.
> > > >
> > > > yes, but it is easily written with an and-expression
> > > >
> > > >   z = not x and 'Not specified' or x.getPref()
> > >
> > > Yikes! The above line of code is a great argument _in favor of_
> > > if-expressions on the basis of readability and maintainability. I couldn't
> > > encourage anyone to use that form.
> >
> > It's the "inverse" of
> >
> >     z = obj.method() if hasattr(obj, 'method') else None
> >
> > which i consider dubious compared to
> >
> >     z = hasattr(obj, 'method') and obj.method()
> 
> No, now the functionality has changed from returning 'Not specified' to
> None. 

I wasn't explicit enough.  My "inverse" was meant as a case where
the expr-if-else syntax can lead to "Yikes!". 

> Besides, it's not just a matter of whether or not the same
> functionality can be produced using a different approach, it's also about
> expressing intent of the code and it's readability. For example, if I were
> hunting for a bug in code that used your "not x and ..." example above,
> realistically I'd slow down and review that piece over and over again each
> time as it's not that obvious what is happening there (to me at least).

I think every ternary operator slows down human parsing.  For that matter

    if x:
        z = x.getPref()
    else:
        z = "not specified"

parses the fastest and is easily understood.  Sure it isn't optimal
with respect to the number of lines but that was never a goal with python. 

> > > > and a ternary op would simply add another possibility.
> > >
> > > ...and hopefully deprecate the usage of your above example, the "simulated
> > > conditional expression".
> >
> > citing from my last mail:
> >
> >     and a ternary op would simply add another possibility.
> 
> Right, I think that's the difference between our two views. IMO, the
> conditional operator would *supercede* the "simulated" conditional
> expressions. So you don't end up with two "valid" possibilities - you end
> up with the normal way to do it and the more hacky way to do it.

And thus might not even learn (or care) that 'and' lets your return 
something other than a boolean. 

> [...]
> > Even if the old way is bad it will be useful in other situations
> > Thus you still have two constructs.  In some cases PEP-308 is better,
> > in others the and-idiom.  But don't forget that *both* will be abused.
> 
> I understand that both have the potential for abuse, but to me the old way
> _is_ an abuse. To me this is a readable and clear idiom:
> 
> x = a or b
> 
> as is this:
> 
> x = a and b

but this might often not be used anymore in a PEP-308 world. 
This and/or behaviour is unfamiliar for many whereas the ternary
op is not.  The abuses of the latter might very well reach the 
same quantity than the problem they try to cure. 

> but going beyond that in terms of complexity and relying on implicit
> precedence rules (instead of grouping with parentheses) is much less
> obvious and easier to screw up.

Statements on easy (i.e. non-ternary) expressions are my favorite :-)

    holger