PEP-308 a "simplicity-first" alternative
pyth at devel.trillke.net
Wed Feb 12 00:49:11 CET 2003
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.
> > 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.
More information about the Python-list