PEP 308: "then" "else" for deprecating "and" "or" side effects

[Tim Peters]

[Mike Orr]
> The tertiary operator is one of those long-requested features that's
> not going to go away, because it's genuinely useful and allows one to
> eliminate an entire if-block, the way a list comprehension eliminates
> an entire for-block.  Rejected or not, the tertieary operator will
> continue to be a FAQ, so we may as well put it in the language now so
> the issue will go away.  That's what we did for '+=' and string
> methods, which were rejected for years for pedantic reasons (+= as
> unnecessary, string methods because "immutable objects don't have
> methods").

This is a bit of revisionist history a bot can't let pass.  Guido was on
record in favor of += in the first year of Python's life, but didn't give it
high priority, and as the years flew by it became clear there were thorny
design issues that needed to be worked out first.  Implementation proceeded
swiftly after they were.  The ascendance of NumPy pushed it along in a big
way (doing "a = a + b" in a memory-efficient way when a and b are
multi-megabytes arrays isn't easy without fiddling the byte code; but it's
straightforward for an __iadd__ method).

String methods were even more of a "sure, but who's got time for it?" thing.
JPython and the introduction of Unicode strings tipped the balance toward
action on that one.

Nothing similar has happened to push conditional expressions to the fore.
When Guido implemented them two years ago (I've given a reference to the
patch on SourceForge several times), he ended up rejecting his patch because
he didn't find good uses in the standard library.  I went through a similar
exercise recently, and found only a few -- but then I'm quite accustomed to
seeing dirt-simple uses of and/or by now, like

    ok and "yes" or "no"

and wouldn't bother to change such existing uses.  You get used to it (which
isn't a ringing endorsement <wink>).

> Python has always been great in adding, not every feature,
> but a few well-chosen features that have wide applicability.

The perceived lack of which (wide applicability) being why Guido rejected
his implementation of conditionals last time around.  I can't say I've seen
many compelling use cases in this incarnation of the beast (and, no, min and
max aren't compelling -- although they would be if they weren't built in
already -- if "functions like that" were common, I'd expect to see some
examples other than min and max <wink>).