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

[Jp Calderone]

On Tue, Feb 18, 2003 at 12:23:57PM -0800, Mike Orr wrote:
> 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").  Python has always been great in adding, not every feature,
> but a few well-chosen features that have wide applicability.  The
> tertiary operator would be a good complement.  (Sets and dict
> comprehensions are two others; fortunately, sets are already here. :)

  I disagree.  Programmers are not, by and large, language developers.  To
say that simply because many people ask for a feature, that feature is
desirable is to completely discard the idea that people who have experience
designing and implementing languages might have a better understanding of
the issues involved.

  It is like saying that a race car driver is qualified to design a car. 
Are they better qualified than the average joe?  Probably.  Are they as
qualified as an engineer at GM?  Unlikely.

  If there are good reasons to add a ternary operator, and people make them
well, then it should be added.  If the only reason is that a lot of people
shout really loudly that they want it, then this is not a compelling reason,
and the operator should not be added.

  Just so you don't think I'm against every language extension, I love
string methods >:) (Augmented assignment was a big mistake, though!)

  Jp

-- 
 up 10 days, 2:28, 5 users, load average: 0.20, 0.11, 0.09
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20030218/40349b84/attachment.sig>