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

[Michael Hudson]

Tim Peters <tim.one at comcast.net> writes:

> [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.

Two can play at that game :-)

> 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.

As I recall it, I got tired of the debates and implemented += and
friends as pure syntactic sugar.  Then Thomas Wouters decided to do
what was necessary to get them into the core (i.e. resolving the
issues you talk about) and did it.  So implementation and
issue-resolution went almost hand in hand.

Basically what got augmented assignment into the core was a couple of
people getting tired of the gassing about it and writing some code
(it's possible this tactic is a bit too effective).

I'm not sure that would help the current debate much, given that
conditional exps hafve been implemented at least once already...

Cheers,
M.

-- 
  SPIDER:  'Scuse me. [scuttles off]
  ZAPHOD:  One huge spider.
    FORD:  Polite though.
                   -- The Hitch-Hikers Guide to the Galaxy, Episode 11