PEP-308 a "simplicity-first" alternative

[holger krekel]

Dave Brueck wrote:
> On Tue, 11 Feb 2003, holger krekel wrote:
> 
> > Every ternary op construct needs time to get used to it, i am afraid.
> 
> Some more than others, of course.

sure. 

> > Everything else would be surprising. From there it's only a short
> > way to "getting it".  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
> >
> > i don't think it's "entirely non-obvious" for you anymore?
> 
> Well, I've tried to objectively "try out" each proposal so far and,
> frankly, this is by far the least readable to me. It's basically the same
> old and-or trick, which IMO isn't readable either.
> 
> What I like about the other proposals is that, even if you aren't familiar
> with them, you have a very good chance of correctly guessing what they are
> trying to express.

Agreed, though guessing what "x and y else z" means is not exactly
impossible.  The goal with this idea is to fix the one problem with 
the current ternary op-idiom not to introduce new "clean" syntax. 

I can understand that you generally dislike the behaviour of current 
and/or expressions not returning bools.  But it's there and it's 
impossible to deprecate it even if we wanted.  

Adding a new expression syntax of its own right and with its own set of 
pros and cons for a "minor feature" (GvR) just doesn't seem right to me. 

regards,

    holger