PEP-308 a "simplicity-first" alternative

[holger krekel]

Peter Hansen wrote:
> holger krekel wrote:
> > 
> > Peter Hansen wrote:
> > > Paul Rubin wrote:
> > > > In fact it's not even obvious what it does.
> > > > What should the value of (2 and 0 else 3) be?
> > >
> > > Hmm... (2 and 0) gives the value 0, so the result should clearly
> > > be whatever (0 else 3) returns, which logically should be 3, right?
> > >
> > > (In other words, I agree.  If you know it's a ternary op, you can
> > > figure it out.  If you don't, it's entirely non-obvious what it's
> > > doing, and reads to me more like a latent syntax error than anything
> > > else.)
> > 
> > Every ternary op construct needs time to get used to it, i am afraid.
> > To me 'else' doesn't hint at a boolean operator like 'or' but
> > 
> >     a) that there is a "not-else" part before it
> 
> When I get to the "else" in that statement, my brain just goes "huh?".
> It stops cold, because "else" and "and" have no semantic relationship
> whatsoever to each other.  I'm sorry, but my brain just doesn't parse
> it even though I know at one level what it's *supposed* to mean.

yip, understandable.  the and/or thingy generally takes an "Oh, what
does this do".  Others think it's practical enough. 

> > In real life examples (taken from stdlib) like
> > 
> >     run==1 and '' else 's'
> >     cl and cl.__name__ else ''
> >     unicode and self.ugettext else self.gettext
> 
> These do nothing for me.  No feeling of comprehensions at all.
> They just sit flat on the screen, devoid of meaning and waiting
> for some kind of translation to words that speak to me.
> 
> > i don't think it's "entirely non-obvious" for you anymore?
> 
> I have to say our brains work in vastly different ways.  Not only
> is it still entirely non-obvious, but no matter how much I look
> at it (up to the finite amount tried to date, anyway), the 
> "and" part gives no sense of a conditional whatsoever.  In fact,
> that's a reason to dislike the current idiom (a and b or c) even 
> apart from the fact that it encourages certain bugs.

I just think it may be non-obvious but "entirely" is a bit much. 
but ok.  I think for people greatly disliking the current and/or idioms
this "fix" proposal must look bad.  I was following a specific strategy
and didn't claim that the and/else "fix" would be satisfying 
in every respect.  But like it or not, there are people who
dislike PEP-308 for yet different reasons.  The danger is there
that we all may have to deal with constructs we each don't like. 

> > Also it's nice that if you discover you don't need an else-part
> > anymore you can just delete it.  With the other proposals you have
> > to rewrite your expression - using another idiom.
> 
> Any time someone writes "it's nice" or "it's a neat trick" in
> a discussion of this nature, I'd like to run screaming from
> the room...  we _eschew_ neat tricks, not embrace them!

Sorry, peter, but this sounds rather formal.  Do you really think 
it's that great a "feature" that you have to switch to another idiom 
if your ternary becomes binary?  Would you like it that with

    if cond:
        ...
    else:
        ...

you decide you don't need the else part and then you have to write 

    ifnoelse cond: 
        ...

instead of taking the "else"-part away?   I may have misphrased 
it but uniformity is not just a neat trick. 

    holger